Správa prostorových dat v prostředí webu

České vysoké učení technické v Praze Fakulta stavební

Diplomová práce

Správa prostorových dat v prostředí webu Petra Svobodova´

§

Vedoucí práce: Ing. Michal Seidl, Ph.D.

Studijní program: Geodézie a kartografie Obor: Geoinformatika leden 2013

Poděkování Ráda bych poděkovala svému vedoucímu diplomové práce Ing. Michalu Seidlovi, Ph.D. za ochotně poskytnuté rady a odborné konzultace při zpracovávání této práce, Ing. Michalu Strelcovi za pomoc při Unit testingu a v neposlední řadě také své rodině za podporu v průběhu celého studia. ii

Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracovala samostatně a že jsem použila jen podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti použití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Zb., o autorském právu, o právech souvisejících s autorským právem a o změně některých zákonů (autorský zákon).

V Praze dne 21. 12. 2012

.............................................................

iii

Abstract This thesis deals with the management of spatial data in the Web environment. This issue is analyzed by creation of Web mapping application. For the implementation was used framework Nette, libraries GeoExt, Ext JS, OpenLayers and PostGIS with PostgreSQL database.

Keywords: PHP, Nette, JavaScript, GeoExt, Ext JS, OpenLayers, PostGIS, AJAX

Abstrakt Tato diplomová práce se zabývá problematikou správy prostorových dat v prostředí webu. Tato problematika je zkoumána na tvorbě ukázkové webové mapové aplikace. K její implementaci byl využit framework Nette, knihovny GeoExt, Ext JS, OpenLayers a databáze PostgreSQL s PostGIS.

Klíčová slova: PHP, Nette, JavaScript, GeoExt, Ext JS, OpenLayers, PostGIS, AJAX

iv

Obsah 1 Úvod

1

2 Analýza systému

3

2.1

Mapové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Obecné požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3

Zajištění integrity dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.1

Přihlašování uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.2

Uzamykání objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.3

Zajištění aktuálnosti dat u klienta . . . . . . . . . . . . . . . . . . . . .

6

2.3.3.1

Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3.3.2

Web Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3 Návrh systému

9

3.1

Řešení problému aktuálnosti dat . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2

Návrh architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.3

Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.4

Funkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.1

Případy užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Návrh databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.5.1

Klasická struktura databáze . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.5.2

Univerzální”struktura databáze . . . . . . . . . . . . . . . . . . . . . . ” 3.5.2.1 Princip univerzální”struktury . . . . . . . . . . . . . . . . . . ” 3.5.2.2 Struktura tabulek pro zajištění integrity dat . . . . . . . . . .

19

22

3.5.2.3

23

3.5

Zhodnocení navrhnuté struktury . . . . . . . . . . . . . . . . .

4 Technologie 4.1

4.2

20

24

PostGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1.1

Simple Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1.2

Open Geospatial Consortium . . . . . . . . . . . . . . . . . . . . . . . .

26

MapServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

v

4.3

4.4

4.5

4.6

4.7

Nette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.3.1

MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

JavaScriptové knihovny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.4.1

GeoExt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.4.2

Ext JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.4.3

OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.4.4

JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.4.4.1

Objektovost jazyka JavaScript . . . . . . . . . . . . . . . . . .

29

4.4.4.2

Události . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.1

Cíle REST architektury . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.2

Omezení REST architektury . . . . . . . . . . . . . . . . . . . . . . . .

32

AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.6.1

XMLHttpRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.6.2

Stavové kódy HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

JSON a GeoJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.7.1

JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.7.2

GeoJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.8

NetBeans IDE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.9

Firebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5 Implementace

39

5.1

Implementace serverové části . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2

Implementace klientské části . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.3

Rozšíření funkcionality OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.3.1

Midpoint snapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.3.2

Snapping při měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.3.3

Událost startDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.4

Použití REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.5

Popis aplikace z pohledu uživatele . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.5.1

Nepřihlášený uživatel . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.5.1.1

Posun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.5.1.2

Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.5.1.3

Měření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

vi

5.5.1.4

Snap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.5.1.5

Přihlášení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Přihlášený uživatel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.5.2.1

Kreslení prvků . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.5.2.2

Editace prvků . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.5.2.3

Rušení prvků . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.5.2.4

Odhlášení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

Popis aplikace z hlediska systému . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.6.1

Načtení stránky, přihlášení uživatele . . . . . . . . . . . . . . . . . . . .

51

5.6.2

Vytvoření nového objektu . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.6.3

Editace objektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.6.4

Smazání objektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

Požadavky na hardware a software . . . . . . . . . . . . . . . . . . . . . . . . .

57

5.7.1

Serverová strana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

5.7.2

Klientská strana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.5.2

5.6

5.7

6 Testování 6.1

6.2

59

Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

6.1.1

Instalace PHPUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

6.1.2

PHPUnit a Nette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

6.1.3

PHPUnit a NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.1.4

Vlastní testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

Výsledky testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7 Zhodnocení

63

7.1

Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.2

Struktura databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

7.3

Funkčnost aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

7.4

Návrhy na rozšíření aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

8 Závěr

67

9 Literatura

69

Přílohy

72

vii

A Seznam digitálních příloh

I

B Diagramy BPMN (Business Process Model and Notation) C Ukázky kódu

III VIII

D Ukázky aplikace

XII

E Unit testing

XVII

viii

Kapitola 1. Úvod

1

1 Úvod

Tématem této diplomové práce je správa prostorových dat v prostředí webu. Tato problematika je zkoumána na tvorbě ukázkové webové aplikace, která bude výstupem této práce. Aplikace bude obsahovat mapu pro zobrazení geometrických objektů s definovanými popisnými vlastnostmi. Uživatelé aplikace budou moci tyto objekty editovat či mazat a také vytvářet objekty nové. Tato práce se zejména zabývá implementací funkcí pro vytvoření, editaci a smazání objektu a dále řešením problémů spojených se zavedením víceuživatelského systému. Konkrétně je řešena kontrola přístupu více uživatelů k prostorovým objektům uloženým v databázi přes uživatelské rozhraní aplikace a zároveň zachování integrity dat v databázi. Kromě tohoto je zde také rozebírán problém zajištění zobrazení aktuálních dat na stránce bez nutnosti častého manuálního obnovování stránky. Tyto problémy spolu s návrhem použitého řešení jsou popsány v podkapitole 2.3. Vzhledem k tomu, že tato aplikace není vytvářena pro konkrétní použití, které by dopředu definovalo typ dat, se kterými má aplikace pracovat, je třeba navrhnout aplikaci tak, aby byla použitelná pro co nejširší okruh typů vektorových prostorových dat. Od tohoto požadavku se odvíjí problém navržení takové struktury databáze, ve které by bylo možné uchovávat mnoho různých typů vektorových dat a následně s nimi pracovat prostřednictvím rozhraní webové aplikace. Návrh struktury databáze, která toto podporuje, je popsán v podkapitole 3.5. Dle zadání jsou v rámci této práce zkoumány technologie PostGIS, PHP framework Nette, JavaScriptové knihovny GeoExt, Ext JS a OpenLayers, které jsou použité při implementaci aplikace. Kromě zadaných knihoven a frameworku jsou v kapitole 4 rozebrány i další volně dostupné technologie, které jsou využité v aplikaci. Způsob realizace navržené aplikace a jak konkrétně výsledná aplikace funguje je přiblíženo v kapitole 5. Jelikož se v průběhu implementace ukázalo, že určité funkcionality, které aplikace

Kapitola 1. Úvod

2

vyžadovala, nejsou použitými technologiemi nabízeny, bylo nutné poskytnutou funkcionalitu rozšířit. Toto rozšíření je popsáno v podkapitole 5.3. V kapitole 7 je práce zhodnocena z hlediska použitých technologií, způsobu implementace a z hlediska celkové funkčnosti aplikace.

Kapitola 2. Analýza systému

3

2 Analýza systému

V této kapitole jsou shrnuty možnosti široce používaných systémů zabývajících se správou prostorových dat a na základě toho jsou stanoveny základní požadavky na aplikaci vytvářenou v rámci této práce. Dále je zde analyzována problematika zajištění integrity dat. Na základě zde stanovených obecných požadavků a provedené analýzy bude aplikace navrhnuta (viz kapitola 3).

2.1

Mapové aplikace

Existuje mnoho široce používaných GIS aplikací, které umožňují spravovat prostorová data. Jedná se zejména o desktopové aplikace, které nabízí širokou škálu funkcí pro práci s prostorovými daty, například zakládání nových objektů, úprava stávajících objektů, tj. základní operace, jako jsou posun, otočení apod., ale i složitější operace, jako různé transformace dat, komplikované analýzy atd. Mezi nejznámější desktopové GIS aplikace u nás patří:

1. ArcGIS společnosti Esri [2] 2. open-source software Quantum GIS (QGIS) šířený pod licencí GNU General Public License [19] 3. MISYS firmy GEPRO spol. s r.o. [9]

Webové aplikace používané širokou veřejností tak rozsáhlou funkcionalitu obvykle nenabízejí. Většinou se jedná pouze o prohlížečky dat a uživatelé nemohou nijak měnit jejich strukturu. Mají možnost například získat popisné informace o prostorových objektech zobrazených v mapě, změřit si vzdálenost či plochu v mapě nebo odečíst souřadnice bodu. Některé aplikace (většinou placené verze) nabízejí také například generování různých výpisů dat, statistik, či vytváření komplikovanějších dotazů. Mezi nejznámější webové GIS aplikace u nás patří:


4

1. Geoportál ČÚZK dostupný na adrese http://geoportal.cuzk.cz/ 2. Národní geoportál INSPIRE dostupný na adrese http://geoportal.gov.cz/ 3. Geoportál GEPRO dostupný na adrese http://geoportal.gepro.cz/

2.2

Obecné požadavky

V předchozí podkapitole byla zmíněna funkčnost nabízená webovými aplikacemi používanými širokou veřejností. Webová aplikace vytvořená v rámci této diplomové práce bude uživatelům umožňovat kromě získání informací o prostorových objektech zobrazených v mapě a měření v mapě i editování, mazání objektů a také vytváření nových objektů prostřednictvím uživatelského rozhraní aplikace. Změny provedené přes uživatelské rozhraní se budou ukládat do databáze. Tato aplikace bude navržena jako víceuživatelská, což znamená, že bude třeba zajistit přístup uživatelů ke stávajícím geoprostorovým objektům tak, aby byla zachována integrita dat.

2.3

Zajištění integrity dat

Navrhovaná webová aplikace je víceuživatelská, což znamená, že se předpokládá, že si stránku s touto aplikací otevře najednou více uživatelů, kteří budou přes ni moci přistupovat do databáze a měnit zde data. To přináší řadu problémů, které je třeba řešit již v návrhu aplikace. Je třeba zajistit zejména integritu dat, což znamená následující:

1. Zajištění, aby si uživatelé aplikace vzájemně nepřepisovali data. 2. Zajištění, aby data uložená v databázi byla konzistentní (tj. aby tabulky neobsahovaly záznamy s cizími klíči odkazujícími na neexistující data). 3. Zajištění, aby data zobrazená na stránce v reálném čase souhlasila s daty uloženými v databázi.

Návrh řešení těchto problémů je nastíněn v následujících podkapitolách.


2.3.1

5

Přihlašování uživatelů

První dva výše uvedené problémy, tj. omezení uživatele zasahovat do dat jiného uživatele a konzistentnost dat v databázi, řeší nastavení přístupu uživatelů pouze k některým objektům. Přičemž množiny přístupných objektů různým uživatelům jsou disjunktní. Každý uživatel bude moci přistupovat pouze k těm objektům, které jsou přiřazené k jeho osobě. Z toho vyplývá potřeba založení uživatelských účtů v databázi. Uživatel, který bude mít přístup k editaci objektů, musí mít zároveň založený účet v databázi. Objekty pak musí mít v databázi přiděleného tzv. vlastníka, tj. přiřazený uživatelský účet. Uživatelé se budou pod těmito uživatelskými účty k aplikaci přihlašovat, čímž se jim zpřístupní editační funkce a objekty přiřazené k jejich účtům k editaci. Pokud vytvoří nový objekt, bude tento objekt automaticky přiřazen k jejich účtu. Nepřihlášený uživatel nebude mít možnost měnit žádný objekt a ani žádný vytvářet.

2.3.2

Uzamykání objektů

Výše uvedeným zabezpečením se zabrání tomu, aby si uživatelé s odlišnými uživatelskými účty mohli vzájemně přepisovat data. Prozatím však není vyřešen případ, kdy se do aplikace přihlásí více uživatelů pod stejným uživatelským jménem a heslem. Pokud by se toto stalo, mohli by tito lidé teoreticky chtít editovat či mazat ten samý objekt. To by opět mohlo zapříčinit nekonzistentnost dat či konflikt při přístupu do databáze. Z tohoto důvodu bylo navrženo tzv. uzamykání objektů. Prakticky se jedná o nastavení příznaku danému objektu v databázi, že byl uzamknut, kým a kdy. Uzamknutí objektu se bude provádět v okamžiku počátku editace objektu. Poté nebude moci žádný uživatel kromě toho, který provedl uzamknutí, objekt editovat či mazat. Opět se bude provádět kontrola i na straně serveru, zda k objektu přistupuje ten uživatel, který ho uzamkl. V případě, že ano, budou změny v databázi provedeny a dojde k odemknutí objektu. Problém by však mohl nastat tehdy, kdyby uživatel, který na počátku editace objekt uzamkl, editaci nedokončil (neodeslal by změny na server) a například by zavřel okno prohlížeče nebo by obnovil stránku. V takovémto případě by zůstal objekt uzamknut pro všechny uživatele. Z tohoto důvodu se do databáze bude ukládat i čas uzamknutí objektu. Při kontrole, zda je objekt uzamčen se pak bude kontrolovat i čas uzamknutí. V případě, že k uzamknutí došlo před více než 1 hodinou, bude objekt systémem odemknut.


2.3.3

6

Zajištění aktuálnosti dat u klienta

V předchozích podkapitolách bylo popsáno, jak bylo navrženo zajištění skutečnosti, aby data uložená v databázi zůstala konzistentní a aby si uživatelé vzájemně nemohli přepisovat data. Dále byl řešen problém, jak zajistit, aby data zobrazená uživateli na stránce v reálném čase odpovídala datům uloženým v databázi. Tento problém by mohl mít následující řešení:

1. Pravidelné dotazování na server, zda nedošlo ke změně dat - tzv. metoda heartbeat” ” 2. Využití technologie Web Socket

Text v této kapitole byl čerpán ze zdroje [23].

2.3.3.1

Heartbeat

Posílání dotazů na server z klientské strany v pravidelných intervalech je poměrně jednoduchá metoda, ale má jeden závažný nedostatek. Časté provádění dotazů na server ze stran mnoha klientů a následné přistupování do databáze a zjišťování, zda nedošlo k nějaké změně v datech, by způsobovalo velkou zátěž na server. Běh aplikace by se tím začala velmi zpomalovat, pracovala by neplynule, což není pro uživatele přijatelné. Z tohoto důvodu není tato možnost doporučována.

2.3.3.2

Web Socket

Technologie Web Socket je založena na dlouhodobém spojení mezi klientem a serverem, prostřednictvím jehož lze posílat data oběma směry. Umožňuje serveru zaslat data klientské straně, případně všem připojeným klientům, aniž by si ona data vyžádali. Klasická webová komunikace mezi serverem a klientem probíhá následujícím způsobem: Klient naváže spojení s webovým serverem prostřednictvím protokolu HTTP a zašle serveru požadavek. Webový server požadavek přijme a na základě toho vyvolá určitou akci. Po provedení této akce zašle zpět klientovi odpověď a spojení ukončí. Data nelze zaslat ostatním klientům, protože mezi nimi a serverem není žádné spojení navázáno. Nové spojení se vytvoří až na základě žádosti určitého klienta.


7

Obrázek 2.1: Diagram komunikace komponent webové aplikace s klasickým webovým serverem. Technologie Web Socket funguje odlišně. Na klientské straně se v kódu JavaScriptu naváže spojení k serveru, prostřednictvím protokolu ws. Server, který musí technologii Web Socket podporovat, toto spojení potvrdí, po čemž lze již posílat obousměrně zprávy, a toto spojení zůstává stále aktivní, dokud ho klient nebo server přímo neukončí. Program s technologií Web Socket však nemůže běžet na obyčejném webovém serveru, který dlouhodobé spojení nedokáže udržet. Proto bývá program s Web Socket samostatný server, který zůstává spuštěný jako služba na určitém stroji. Komunikace mezi klienty a serverem je znázorněna na následujícím diagramu.

Obrázek 2.2: Diagram komunikace komponent webové aplikace s Web Socket serverem.

Klient, který provedl změnu v datech, o tom zašle zprávu Web Socket serveru. Ten následně rozešle zprávy všem ostatním připojeným klientům, kteří na základě toho provedou request na webový server, kde si zažádají o aktuální data. Technologie Web Socket je závislá na softwaru běžícím na klientské straně, konkrétně na we-


8

bovém prohlížeči. V současné době již většina webových prohlížečů podporuje alespoň základní funkcionalitu Web Socket. Jedná se o tyto základní funkce:

1. vytvoření instance třídy Web Socket - u prohlížečů s vyjímkou Mozilly Firefox je to zpravidla prováděno příkazem new WebSocket(), Mozilla podporuje syntaxi new MozWebSocket() 2. otevření spojení s Web Socket serverem - funkce open() 3. zaslání zprávy Web Socket serveru - funkce send() 4. uzavření spojení s Web Socket serverem - funkce close()

Ke zprovoznění aplikace založené na této technologii je zejména třeba naimplementovat ovládání spojení s klienty ze strany Web Socket serveru. Lze využít některou z volně dostupných knihoven, které implementují klientskou i serverovou část pro komunikaci přes Web Socket. Známá je například knihovna socket.io implementovaná v jazyce JavaScript pro klientskou i serverovou stranu. Dále existuje knihovna pywebsocket implementovaná v jazyce Python, také php-websocket napsaná v jazyce PHP a další.

Kapitola 3. Návrh systému

9

3 Návrh systému

Na základě možných řešení problému zobrazení aktuálních dat na stránce uživatelů analyzovaných v podkapitole 2.3.3, je v této kapitole navrhnuto konkrétní řešení použité v této aplikaci. Dále je zde proveden návrh architektury systému, stanovení uživatelských rolí a konkrétních funkčních požadavků na aplikaci. Aplikace nemá prozatím žádné konkrétní využití, její implementace slouží především k seznámení a prozkoumání možností veřejně dostupných technologií určených pro programování webových mapových aplikací. Není tedy předem jasné, jaký typ dat se bude jejím prostřednictvím spravovat. Bude tedy navržena tak, aby byla připravena pro správu co největšího množství typů dat. K tomuto je třeba uzpůsobit návrh databáze, což je řešeno v podkapitole 3.5. V databázi budou předem nadefinovány některé typy dat, z kterých pak uživatel aplikace bude mít na výběr při vytváření nového objektu.

3.1

Řešení problému aktuálnosti dat

V podkapitole 2.3.3 byl nastíněn problém zobrazení aktuálních dat z databáze na stránce uživatelů aplikace. Byla zde zanalyzována možná řešení tohoto problému, která spočívala v použití metody heartbeat”nebo v zavedení technologie Web Socket. ” Použití metody heartbeat”bylo zavrhnuto a to z toho důvodu, že by vznikala velká zátěž na ” server, což by způsobovalo nepřiměřené zpomalování běhu aplikace. Technologie Web Socket se ukázala jako vhodná pro zavedení do této webové aplikace, což je jedním z námětů na její budoucí rozšíření a zdokonalení. V rámci této diplomové práce nebyla tato technologie z časových důvodů využita. Pro použití v aplikaci byl navržen následující způsob řešení problému aktuálnosti dat. Klient před začátkem provádění změn dat na klientské straně zašle request na server. Webový server v databázi zkontroluje, zda má klient na stránce zobrazená aktuální data, případně se


10

klientovi zašlou zpět. U klienta v mapě se data zaktualizují, klient pak provede změny a zašle je na server. Tyto změny se uloží do databáze a provede se další kontrola aktuálnosti dat. Tato druhá kontrola se po zapsání změn v databázi bude provádět proto, že klient může z různých důvodů pozdržet zaslání dat na server. Může například delší dobu vytvářet nový objekt nebo ho editovat a této době již mohl jiný uživatel provést změny v databázi, o kterých by se jinak tento uživatel nedozvěděl až do okamžiku počátku další editace. Toto řešení má tu výhodu, že nedochází k velkému zatížení serveru častými dotazy na data, jak by tomu bylo v případě metody heartbeat”. Přitom se klient o případné změně v datech ” dozví ještě před provedením vlastních změn, tedy v okamžiku, kdy to nejvíce potřebuje vědět. Zároveň bude aplikace navržena tak, aby se maximálním možným způsobem využíval každý zaslaný požadavek na serverovou stranu, tj. aby nedocházelo ke zbytečně mnoha requestům, které požadují malé množství dat.

3.2

Návrh architektury

V této podkapitole je uveden návrh architektury této webové aplikace. Aplikace se bude skládat z komponent znázorněných na diagramu 3.1.

Obrázek 3.1: Diagram komponent webové aplikace

Jak je na diagramu znázorněno, bude na serverové straně umístěna část aplikace založená na PHP frameworku Nette (viz kapitola 4.3). Přes třídy tohoto frameworku bude aplikace přistupovat do PostgreSQL databáze s knihovnou PostGIS (viz kapitola 4.1), kde budou umístěna data. Prostřednictvím HTTP protokolu bude server komunikovat s klientskou částí aplikace


11

napsanou v jazyce JavaScript. Část aplikace u klienta bude používat knihovny frameworků Ext Js, GeoExt a OpenLayers (viz kapitola 4.4). Komunikace mezi klientem a serverem bude dodržovat zásady REST architektury (viz kapitola 4.5) a požadavky zasílané klientem na server budou prováděny prostřednictvím metod definovaných touto architekturou.

3.3

Uživatelské role

Na základě analýzy v kapitole 2.3.1 byly navrženy 2 uživatelské role. Jedná se o roli Guest a User. Role Guest reprezentuje uživatele, který buď nemá založený žádný uživatelský učet nebo ho má, ale nepřihlásil se pod ním do aplikace. Tuto roli dostane přidělenou každý uživatel, který vstoupí na stránky této aplikace. Druhá role s pojmenováním User reprezentuje již přihlášeného uživatele k aplikaci. Tento uživatel má tedy v databázi založený uživatelský účet, kde je uloženo uživatelské jméno a heslo. Toto jméno a heslo musel uživatel zadat do přihlašovacího formuláře na stránce aplikace a pokud byla správnost těchto údajů ověřena v databázi, byl uživatel přihlášen. V okamžiku přihlášení se z role Guest stává role User. Rozdíl mezi těmito uživatelskými rolemi je v přístupnosti funkcionality aplikace. Uživatel s přidělenou rolí Guest má přístupné pouze základní funkce. Má právo používat pouze tzv. informativní funkcionalitu, ale nemá právo jakkoli zasahovat do databáze a měnit strukturu dat. Kdežto uživatel s rolí User má kromě tzv. informativních funkcí již zpřístupněné také funkce, které mění obsah databáze. Konkrétně jsou funkce přístupné oběma rolím popsány v následující podkapitole 3.4. V diagramu 3.2 je znázorněn vztah navržených uživatelských rolí. Šipka mezi aktéry naznačuje, že role User má stejná práva jako role Guest a navíc má právo na použití rozšířené funkcionality aplikace. Obvykle bývá v aplikacích zavedena i role Administrator, který má nejvyšší práva v přístupu k funkcionalitám aplikace. Předmětem této diplomové práce však nebylo vytvoření uživatelského rozhraní pro tuto roli a proto zde není ani uváděna.


12

Obrázek 3.2: Uživatelské role

3.4

Funkční požadavky

V podkapitole 2.2 byly stanoveny obecné požadavky na aplikaci vytvářenou v rámci této práce. Na základě toho byly sestaveny konkrétní funkční požadavky uvedené pod tímto textem. 1. Nepřihlášený uživatel má mít možnost: (a) provádět základní operace s mapou - posun, zoom (b) shlédnout geometrické i popisné vlastnosti všech objektů, které jsou uloženy v databázi (c) použít funkce Měření v mapě - odečet souřadnic bodů, změření vzdálenosti mezi 2 nebo více body, změření plochy definováním lomových bodů 2. Nepřihlášený uživatel nemá mít možnost: (a) založit nový objekt (b) měnit geometrické či popisné atributy jakéhokoliv objektu (c) smazat jakýkoliv objekt 3. Přihlášený uživatel má mít možnost: (a) provádět stejné operace jako nepřihlášený uživatel (b) založit nový objekt určitého typu, tj. definovat jeho geometrické a popisné vlastnosti a uložit je do databáze (c) upravit geometrické či popisné atributy objektu, který dříve založil (d) smazat objekt, který dříve založil 4. Přihlášený uživatel nemá mít možnost: (a) měnit geometrické či popisné atributy objektu, který založil jiný uživatel (b) smazat objekt, který založil jiný uživatel


3.4.1

13

Případy užití

Na základě výše uvedených funkčních požadavků byl sestaven následující diagram případů užití:

Obrázek 3.3: Use Case diagram aplikace.

Název případu užití

Zobrazit popisné informace k objektu

Identifikace případu užití

UC01

Aktéři

Guest

Omezení na stav systému před spuštěním pří-

Zadání URL adresy do webového přohlížeče

padu užití

Hlavní tok událostí: 1. Guest vybere v menu funkci Info” ” 2. Guest klikne na libovolný objekt v mapě 3. Aplikace zobrazí tabulku s výpisem vlastností objektu


14


Odečíst polohu bodu v mapě


UC02

Aktéři

Guest



padu užití

Hlavní tok událostí: 1. Guest vybere v menu funkci Souřadnice” ” 2. Guest klikne do mapy 3. Aplikace zobrazí okénko se souřadnicemi zadaného bodu v S-JTSK


Změřit vzdálenost mezi body v mapě


UC03

Aktéři

Guest



padu užití

Hlavní tok událostí: 1. Guest vybere v menu funkci Měření délky” ” 2. Guest zadá v mapě lomové body měřící linie 3. Aplikace zobrazí okénko s výslednou délkou mezi zadanými body v m


Změřit plochu v mapě


UC04

Aktéři

Guest



padu užití

Hlavní tok událostí: 1. Guest vybere v menu funkci Měření plochy” ” 2. Guest zadá v mapě lomové body měřící plochy 3. Aplikace zobrazí okénko s výslednou plochou v m2


15


Přihlásit se


UC05

Aktéři

Guest



padu užití

Hlavní tok událostí: 1. Guest vyplní uživatelské jméno a heslo do přihlašovacího formuláře 2. Aplikace ověří zadané přihlašovací údaje 3. Aplikace přihlásí uživatele 4. Aplikace zobrazí editační funkce v menu

Alternativní tok: 1. K bodu 1. hlavního toku: Pokud Guest zadal nesprávné přihlašovací údaje, aplikace uživatele upozorní na nesprávně zadané údaje, ukončí případ užití.


Vytvořit geometrii objektu


UC06

Aktéři

User

Omezení na stav systému před spuštěním případu užití

Spuštění funkce Kreslení prvků” ”

Hlavní tok událostí: 1. User vytvoří geometrii buď přímo klikáním v mapě nebo vkládáním bodů definováním jejich souřadnic 2. User ukončí kreslení dvojklikem v mapě nebo kliknutím na tlačítko Ukonči” ” 3. Aplikace zobrazí nakreslený objekt v mapě

Alternativní tok: 1. K bodu 2. hlavního toku: Pokud User klikne na tlačítko Zruš”, aplikace zruší kreslení a ” ukončí případ užití.


16


Změnit geometrii objektu


UC07

Aktéři

User


Spuštění funkce Editace prvků” ”

Hlavní tok událostí:

1. Aplikace zpřístupní lomové body a virtuální body”objektu ” 2. User pozmění polohu lomových bodů, vloží nový bod vytažením virtuálních bodů”, ” případně smaže lomový bod


Definovat popisné informace k objektu


UC08

Aktéři

User


Spuštění funkce Kreslení prvků”nebo Edi” ” tace prvků”

padu užití


1. Aplikace zobrazí formulář pro vyplnění vlastností objektu 2. User vyplní údaje ve formuláři


Vytvořit objekt


UC09

Aktéři

User


Přihlášení do systému


1. User vybere v menu Kreslení prvků”funkci pro kreslení některého typu objektu ” 2. Spuštění případu užití UC06 3. Spuštění případu užití UC08 4. User klikne na tlačítko odeslat” ” 5. Aplikace uloží objekt do databáze


17

6. Aplikace skryje formulář

Alternativní tok:

1. K bodu 4. hlavního toku: Pokud User klikl na tlačítko zrušit”, aplikace smaže nakreslený ” objekt z mapy, skryje formulář a ukončí případ užití.


Editovat objekt


UC10

Aktéři

User




1. User vybere v menu funkci Editace prvků” ” 2. User vybere objekt pro editaci 3. Spuštění případu užití UC07 4. Spuštění případu užití UC08 5. User klikne na tlačítko odeslat” ” 6. Aplikace uloží změny do databáze 7. Aplikace skryje formulář

Alternativní tok:

1. K bodu 5. hlavního toku: Pokud User klikl na tlačítko zrušit”, aplikace zruší provedené ” změny, skryje formulář a ukončí případ užití.


Smazat objekt


UC11

Aktéři

User




1. User vybere v menu funkci Rušení prvků” ”


18

2. User vybere kliknutím svůj objekt pro smazání 3. Aplikace zobrazí potvrzovací dialog 4. User akci potvrdí kliknutím na tlačítko OK” ” 5. Aplikace zavře potvrzovací dialog a smaže objekt z databáze

Alternativní tok:

1. K bodu 2. hlavního toku: Pokud User vybral kliknutím objekt jiného uživatele, aplikace zobrazí upozornění a ukončí případ užití. 2. K bodu 4. hlavního toku: Pokud User klikne na tlačítko zrušit”, aplikace zavře potvr” zovací dialog a ukončí případ užití.


Odhlásit se


UC12

Aktéři

User




1. User klikne na tlačítko Odhlásit se” ” 2. Aplikace odhlásí uživatele 3. Aplikace odstraní editační funkce z menu

3.5

Návrh databáze

Ze zadání vyplývá základní požadavek na databázi a to schopnost uchovávat a pracovat s prostorovými daty. K tomuto účelu je vhodné využít databázi PostgreSQL s knihovnou PostGIS (viz podkapitola 4.1), která poskytuje funkce pro práci s prostorovými daty. Tuto funkcionalitu mimo jiné nabízí i databáze MySQL verze 5+. Návrh struktury databáze se zpravidla odvíjí od konkrétního zadání, zejména od typu a struktury dat, s jakým bude aplikace pracovat. Na základě toho se následně navrhne struktura jednotlivých tabulek a jejich vzájemné relace.


3.5.1

19

Klasická struktura databáze

Ve většině případů je dopředu známé, s jakými daty bude aplikace pracovat a jaká data by tedy databáze měla uchovávat. Na základě toho lze pak celkem snadno navrhnout celou strukturu databáze. Pokud by šlo například o aplikaci evidující komunikace na určitém území, databáze by se navrhla přímo na míru této situaci a vypadala by zjednodušeně třeba následovně:

Obrázek 3.4: Zjednodušený návrh struktury databáze s konkrétním zadáním typu evidovaných dat.

Tento jednoduchý návrh umožňuje ukládat kromě polohy a geometrie komunikace (atribut geometry) také popisné informace jako kategorie (dálnice / silnice / místní komunikace / účelová komunikace), materiál povrchu komunikace, číselné označení, návrhovou rychlost, šířku komunikace atd.

3.5.2

Univerzální”struktura databáze ”

V našem případě však nemáme předem specifikováno, s jakým konkrétním typem dat má aplikace pracovat. Proto bylo třeba navrhnout takovou strukturu databáze, která by se blížila k univerzalitě, byla by použitelná pro co největší množství typů vektorových dat a nový typ nebo jeho vlastnosti by se mohly kdykoliv doplnit, aniž by se muselo zasahovat do kódu samotné aplikace. Navržený model databáze vypadá následovně:


20

Obrázek 3.5: Návrh struktury univerzální databáze. 3.5.2.1

Princip univerzální”struktury ”

Princip tohoto modelu spočívá v tom, že popisné vlastnosti všech typů objektů jsou uloženy v jedné tabulce - PROPERTIES, hodnoty k těmto vlasnostem jsou uloženy v tabulce VALUES, geometrie objektů spolu s doplňkovými údaji, o kterých bude řeč později, je uložena zvlášť v tabulce OBJECTS a typy objektů v tabulce TYPES OBJ. V případě, že bude potřeba doplnit určitou popisnou vlastnost objektu, není třeba měnit strukturu a zakládat další atribut nebo vytvářet novou tabulku spolu s cizími klíči v ostatních tabulkách, jako by tomu bylo v předcházejícím konkrétním případě databáze komunikací, ale stačí vložit nový řádek do tabulky PROPERTIES a do propojovací tabulky TYPES OBJ PROP. V tabulce PROPERTIES je třeba definovat atributem type datový typ hodnot dané vlastnosti. Podle tohoto, se pak hodnota vyplňuje do určitého atributu v tabulce VALUES. Pod atributem value int jsou uloženy hodnoty typu integer, pod atributem value char jsou uloženy hodnoty typu character atd. V případě, že by pro danou vlastnost připadaly v úvahu pouze hodnoty z určitého výběru (například vlastnost Ulice), uloží se tyto hodnoty do číselníku, který reprezentuje tabulka SELECT VAL. Vlastnost bude mít v takovémto případě atribut type rovný hodnotě select”a ” v tabulce VALUES bude místo konkrétní hodnoty odkaz v podobě cizího klíče do tabulky SELECT VAL. Pro větší názornost je na obrázku 3.6 ukázka dat z tabulek PROPERTIES, VALUES a SELECT VAL.


21

Obrázek 3.6: Ukázka dat v tabulkách PROPERTIES, VALUES a SELECT VAL. Z obrázku ukázky hodnot v tabulkách vyplývá, že objekt s id 166 má vlastnosti Počet pater”s ” hodnotou 2, Datum dokončení stavby”s hodnotou 2011-09-19, Ulice”s hodnotou Nerudova a ” ” Výměra”s hodnotou 80,5 m. ” Atribut required v tabulce PROPERTIES určuje, zda je daná vlastnost objektu na uživateli požadovaná (musí být vyplněna) nebo ne. Toto se bude využívat při vytváření formuláře na klientské straně v akci založení nového objektu či jeho editaci (viz celá kapitola 5.6). V tabulce TYPES OBJ jsou definovány všechny typy objektů, které lze v aplikaci vytvořit. Atribut color určuje barvu zobrazení daného objektu na mapě. Atribut geom type je typu geom type, který byl nově vytvořen níže uvedeným příkazem a jehož povolené hodnoty jsou pouze point”/ line”/ polygon”, což se využívá při tvorbě nového objektu (viz podkapitola ” ” ” 5.6.2).

CREATE TYPE geom_type AS ENUM (’point’, ’line’, ’polygon’);

Pokud vznikne potřeba založit nový typ objektu, vytvoří se pouze nový záznam v této tabulce TYPES OBJ a ve spojovací tabulce TYPES OBJ PROP se mu přiřadí vlastnosti. V tabulce OBJECTS je evidována geometrie objektů (atribut geom), typ objektu v podobě cizího klíče k tabulce TYPES OBJ, vlastník objektu (uživatel, který objekt vytvořil a který jediný má právo ho editovat) v podobě cizího klíče ukazující do tabulky USERS. Dále jsou zde atributy time insert a time update označující čas založení objektu v databázi a čas poslední úpravy.

Kapitola 3. Návrh systému 3.5.2.2

22

Struktura tabulek pro zajištění integrity dat

V tabulce OBJECTS jsou dále velmi důležité atributy locked, locks id a lock time, které definují, zda je daný objekt zamknutý pro editaci, kým byl případně zamknut a kdy. Problematika zamykání objektů byla navržena v podkapitole 2.3.2 a jak přesně probíhá je popsáno v podkapitole 5.6.3. V tabulce USERS je kromě jména zobrazeného po přihlášení do aplikace, unikátního uživatelského jména a hesla potřebného k přihlášení, také atribut time check. Tento čas označuje ke každému uživateli dobu poslední provedené kontroly aktualizace dat. Při kontrole aktuálnosti (viz podkapitola 3.1) se u každého objektu porovná čas poslední úpravy time update s tímto časem kontroly time check. V případě, že čas úpravy u objektu je vyšší než čas kontroly konkrétního uživatele, znamená to, že tento uživatel nemá na stránce zobrazena aktuální data. Proto se mu spolu s odpovědí na request, při kterém se provádí kontrola aktualizace dat, zašlou data o tomto konkrétnímu objektu, aby se na klientské straně přepsala (konkrétní implementace zasílání dat k aktualizaci je popsána v podkapitole 5.6). Kromě atributu time update se také porovnává hodnota atributu time del v tabulce DELETED OBJ. Do této tabulky se budou ukládat id smazaných objektů z tabulky OBJECTS, aby si uživatelé mohli u sebe na klientské straně zaktualizovat i smazané objekty, tj. odstranit z mapy objekty s id uvedeným v této tabulce. Klientovi se budou zasílat id těch objektů, které mají čas smazání time del vyšší než je čas kontroly konkrétního uživatele time check. Aby se v tabulce DELETED OBJ zbytečně neudržovali záznamy o dříve smazaných objektech, bude se tato tabulka průběžně promazávat. Ty záznamy, které mají atribut time del nižší než je minimální čas aktualizace time check všech uživatelů aplikace, budou z této tabulky smazány. To se může provést, protože je zaručeno, že všichni uživatelé o těchto smazaných datech ví (mají je smazány i u sebe v mapě). Integrita dat je také z části zajištěna již na úrovni databáze. Tabulky mají definovaný primární klíč a cizí klíče. Tímto je zaručeno, že nelze smazat záznam z tabulky, na který ukazuje cizí klíč jiné tabulky, a způsobit tak nekonzistentnost dat. Tabulky USERS a DELETED OBJ mají dále nastavené omezení na unikátnost atributů username a id smazaného objektu. Uložení korektních dat v databázi je také podpořeno správným nastavením datových typů atributů. Není tedy dovoleno uložit například do atributu s datovým typem integer textový řetězec nebo například do atributu geom type v tabulce TYPES OBJ jinou hodnotu než point”, line”či ” ”


23

polygon”. ”

3.5.2.3

Zhodnocení navrhnuté struktury

Výhody navržené struktury databáze jednoznačně spočívají v jejím širokém využití. V případě, že však dopředu víme, jaká data, zde budou evidována, jak tomu je ve většině případů, pak je rozhodně lepší použít klasickou strukturu databáze naznačenou výše na příkladě databáze komunikací. Nevýhoda mnou navržené struktury je její složitost, která se projeví zejména ve tvorbě SQL dotazů. Použití těchto složitějších SQL dotazů by mohlo při velkém množství dat v databázi přispět ke zpomalení běhu aplikace. Další nevýhodou je řídkost”tabulky VALUES, ” neboť hodnoty vlastností se ukládají vždy jen do 1 ze 7 sloupců. Tato skutečnost způsobuje, že navržená struktura databáze nesplňuje 3. normální formu, tj. všechny neklíčové atributy nejsou vzájemně nezávislé.

Kapitola 4. Technologie

24

4 Technologie

V této kapitole jsou popsány technologie využívané k implementaci webových aplikací a také technologie speciálně využívané k tvorbě webových mapových aplikací. V textu této práce jsou pro větší názornost vysvětlovaného problému uvedeny diagramy. Tyto diagramy byly vytvářeny v programu Enterprise Architect v. 9.3 (viz zdroj [4]) a Bizagi modeler v. 2.1.0.1 (viz zdroj [3]).

4.1

PostGIS

PostGIS je open-source software, který rozšiřuje objektově-relační databázi PostgreSQL o podporu geoprostorových objektů. PostGIS implementuje specifikaci Simple Features konsorcia Open Geospatial Consortium (OGC). Poskytuje všechny geometrické typy objektů definované v Simple Features, umožňuje uložení geometrie ve 2D, 3D i 4D ([x, y, z, m], kde m je hodnota linerárního referenčního systému), podporuje pokročilé prostorové operace, jako je transformace geometrie, vytvoření bufferu, konvexního obalu, generalizace, sjednocení atd., dále funkce pro měření vzdálenosti a plochy, funkce pro analýzu vztahů mezi geometriemi objektů (průnik, rovnost, nejbližší soused, zda objekt obsahuje druhý atd.) a další. [17] PostGIS byl vydán pod licencí GNU General Public License a je neustále vyvíjen pod vedením firmy Refractions Research Inc a rozšiřován o další funkce. [18] K databázi PostgreSQL s knihovnou PostGIS lze přistupovat prostřednictvím programu pgAdmin III. Při vývoji aplikace byl využit pgAdmin III v. 1.14.2.

4.1.1

Simple Features

Simple Features je standard definující zápis geometrických objektů do digitální podoby a operace s těmito objekty. Zápis geometrie se provádí například ve formátu Well-known text (WKT)


25

nebo Well-known binary (WKB). Well-known text je textový značkovací formát určený nejen pro zápis geometrie objektů, ale například i pro definici souřadnicového systému, popis transformačních parametrů mezi dvěma systémy atd. Well-known binary je formát zápisu v binární formě a je určen k převodu dat a uložení do databáze. Geometrické objekty specifikované v Simple Features, jsou následující: [30]

1. Point - bod 2. Curve – posloupnost bodů 3. LineString – lomená čára 4. Line – linie mezi 2 body 5. LineRing – uzavřená nebo neuzavřená křivka 6. Polygon – mnohoúhelník definován vnější a případně i vnitřní hranicí (může být děravý”) ” 7. MultiPoint – množina bodů 8. MultiLineString – množina lomených čar 9. MultiPolygon – množina polygonů 10. GeometryCollection – množina různých geometrických objektů

Příklady zápisu geometrických objektů ve formátu WKT: LINESTRING(1 2, 9 8, 15 20) POLYGON((1 4, 4 1, 7 4, 4 7, 1 4),(3 3, 5 3, 5 5, 3 5, 3 3)) MULTIPOINT(5.6 8.7, 2.1 12.5) MULTIPOLYGON(((1 4, 4 1, 7 4, 4 7, 1 4),(3 3, 5 3, 5 5, 3 5, 3 3)), ((3 3, 6 2, 6 4, 3 3))) GEOMETRYCOLLECTION(POINT(30 5),LINESTRING(8 12,6 3))


4.1.2

26

Open Geospatial Consortium

Text v této podkapitole byl čerpán ze zdroje [12]. OGC je mezinárodní sdružení 478 firem, vládních agentur a vysokých škol s cílem vytvořit komplexní prostorové informace a služby, které jsou přístupné a užitečné všem druhům aplikací. OGC specifikace se týkají:

1. katologových služeb - Catalogue Service for Web (CSW) 2. služeb pro operace s prostorovými daty - například Web Processing Service (WPS), Coordinate Transformation Service (CTS) 3. formátů prostorových dat - například Geography Markup Language (GML), Keyhole Markup Language (KML) 4. služeb poskytujících data - například Web Coverage Service (WCS), Web Feature Service (WFS) 5. služeb zobrazujících data - Web Map Service (WMS), Web Map Tiling Service (WMTS)

4.2

MapServer

MapServer je open-source platforma určená pro publikování prostorových dat v prostředí webu a vytváření interaktivních webových aplikací. V základní podobě je MapServer CGI-program umístěný na webovém serveru. S pomocí údajů uvedených v URL požadavku a v konfiguračním souboru Mapfile vytvoří obraz požadované mapy v různých rastrových či vektorových formátech. Zdrojem prostorových dat pro zpracování Mapservem mohou být data uložená v databázi (PostgreSQL+PostGIS, MySQL, Oracle aj.), vektorová data uložená v souborech (shapefile, DGN apod.) či rastrová data (TIFF, GIF, PNG, JPEG). MapServer je možné zprovoznit na operačním systému Linux, Windows, Mac OS X, Solaris aj. Tento text byl čerpán ze zdroje [24].


4.3

27

Nette

Nette je open-source framework sloužící k vytváření webových aplikací v jazyku PHP v. 5. Nette je vyvíjeno českou komunitou Nette Foundation a je zaměřeno na vysoký výkon a eliminaci bezpečnostních rizik. Využívá architekturu MVC (Model-View-Controller), která zaručí přehlednost kódu a možnost snadného rozšíření aplikace v budoucnu.

4.3.1

MVC

MVC architektura rozděluje kód aplikační logiky (model), kód zobrazující data (view) a kód řídící logiky (controller). V Nette jsou na základě této architektury soubory se zdrojovými kódy aplikace rozčleněny do adresářů. Model bývá v Nette reprezentován soubory v adresáři app/models/. Je to například soubor Model.php s třídou Model, jejíž metody přistupují do databáze (provádějí výběry, vkládání i mazání dat). View je v Nette tvořen soubory v adresáři app/templates/. Těmto souborům se říká šablony, mají příponu *.latte a jejich syntaxe je podobná syntaxi jazyka HTML. Úkolem vrstvy view je definovat vzhled jednotlivých stránek aplikace a zobrazit data. Controller v Nette tvoří tzv. presentery, které jsou uloženy v adresáři app/presenters/. Presentery na základě požadavku uživatele volají aplikační logiku z modelu a předávají data do vrstvy view.

4.4 4.4.1

JavaScriptové knihovny GeoExt

Dle doporučení v zadání byl k vytvoření webové mapové aplikace použit javascriptový framework GeoExt. Tento open-source nástroj spojuje mapovou knihovnu OpenLayers a javascriptové API Ext JS pro tvorbu uživatelského rozhraní. GeoExt například umožňuje umístění mapy do mapového panelu, který objekt třídy”(viz podkapitola 4.4.4.1) Ext JS dokáže zobrazit na ” stránku, a poskytuje nástroje k ovládání mapy prostřednictvím tlačítek v mapovém panelu. Tato knihovna je šířena pod licencí BSD.


28

V nedávné době byla vytvořena nová verze frameworku Ext JS (Ext JS v. 4) a v návaznosti na tuto událost se v dubnu 2012 začala budovat i nová verze GeoExt (GeoExt v. 2). Tato verze však v současné době není definitivní, je stále ve fázi úprav a ani dokumentace tudíž není hotova. Na prozatímních stránkách GeoExt v. 2 [6] jsou již uvedeny základní příklady použití API této verze, což bylo pro vytvoření mé mapové aplikace dostačující. O funkčnost aplikace se totiž z naprosté většiny stará knihovna OpenLayers, jejíž dokumentace je kompletní a zcela přehledná (viz [13]).

4.4.2

Ext JS

Ext JS, produkt společnosti Sencha, je široce rozšířené javascriptové API používané k tvorbě rozsáhlých webových aplikací. Tato sada nástrojů umožňuje vytvořit přívětivé uživatelské rozhraní a bezproblémů ho zobrazit v kterémkoli z nejznámnějších internetových prohlížečů: [20]

1. Internet Explorer 6+ 2. Firefox 3.6+ 3. Safari 4+ 4. Chrome 10+ 5. Opera 11+

V současné době knihovna nabízí využití nejrůznějších formulářových prvků s pokročilou validací, různých typů menu, grafů, balíčku pro kreslení využívajícího formát SVG VML aj. Funkčnost tohoto frameworku však byla v mé aplikaci využita pouze z malé části, a to k vytvoření tlačítek a menu v mapovém panelu, formuláře pro editaci popisných informací objektů a k vlastnímu zobrazení mapového panelu na stránce. Knihovna Ext JS je šiřitelná pod 3 různými typy licencí - komerční, komerční OEM licence a open-source licence (GNU GPL v3). Programátor využívající open-source licenci má povinnost poskytnout svůj kód a to pod stejnou licencí (GNU GPL v3), zatímco programátor se zakoupenou komerční licencí má právo zdrojový kód aplikace neposkytovat. Vývojář se zakoupenou komerční OEM licencí může aplikaci vydávat pod libovolnou svojí licencí.


4.4.3

29

OpenLayers

OpenLayers je javascriptová knihovna určená pro vizualizaci mapových podkladů na webových stránkách a to s podporou většiny moderních prohlížečů. Tento nástroj je open-source a je šířen pod licencí BSD. Knihovna OpenLayers dokáže pracovat se všemi formáty geoprostorových dat specifikovanými konsorciem OGC (viz podkapitola 4.1.2). Obsahuje nástroje pro nakonfigurování mapy do různých projekcí, transformaci dat z jedné projekce do druhé, měření v mapě, kreslení objektů a jejich editaci a mnoho další funkcí (viz dokumentace [13]). OpenLayers tvoří základ této mapové aplikace. Jejich studiu byla věnována největší pozornost a jejich kód byl pro tuto aplikace navíc rozšířen o další funkcionality (viz kapitola 5.3). V této mapové aplikaci byla využita verze OpenLayers 2.12. V současné době již se pracuje na nové verzi knihovny (OpenLayers v. 3), která slibuje kromě zlepšení výkonu, hezčích vizuálních komponent a lepšího API, také například podporu zobrazování 3D grafiky. [14]

4.4.4

JavaScript

JavaScript je objektově orientovaný skriptovací jazyk, používaný zejména k tvorbě webových stránek. Program se většinou spouští na straně klienta, tj. až po stažení webové stránky z internetu (narozdíl od většiny ostatních jazyků, například PHP, který se spouští na straně serveru). JavaScript je však možné použít i na serverové straně, viz projekt Node.js [11].

4.4.4.1

Objektovost jazyka JavaScript

JavaScript má oproti ostatním objektově orientovaným jazykům odlišnost v tom, že nemá klasické třídy. Absence tohoto konstrukčního prvku, typického pro objektově orientované jazyky, se však nahrazuje pomocí funkcí. Ukázka kódu JavaScriptu na obrázku C.1 v příloze znázorňuje, jak taková syntaxe vypadá. Na tomto příkladě je zároveň také naznačen princip zapouzdření, jednoho z vlastností objektově orientovaných jazyků. Podobně budou demostrovány i další vlastnosti - polymorfismus a dědičnost. Všechny tyto ukázky mají za úkol dokázat, že ačkoliv jazyku JavaScript chybí tak typický prvek pro objektově orientované jazyky, jako je Třída, není oproti ostatním jazykům nijak znevýhodněn, neboť je tento prvek se všemi jeho vlastnostmi dokonale nahrazen.


30

Příklad kódu na obrázku C.2 je opět velmi jednoduchý a není příliš vhodný k využití polymorfismu, přesto tuto vlastnost demonstruje. V ukázce je metoda třídy Company2 definována tak, že zavolá metodu třídy Company ale na svém objektu. K tomu je využita funkce call. Na obrázku C.3 je demostrována dědičnost, v níž třída Company2 zdědí z třídy Company. V této ukázce je využita funkce apply(), s jejíž pomocí jsou dědící třídě Company2 přiřazeny proměnné a metody rodičovské třídy Company, které nejsou v prototype. Většinou je ale vhodné dávat všechny metody třídy do prototype, protože lze pak snadno upravit některou metodu a změna se projeví u všech instancí třídy (i u těch již vytvořených). Třída Company2 pak zdědí všechny metody z prototype z pomocného kontruktoru F, jak je v ukázce naznačeno. Na obdobném principu dědičnosti funguje metoda Class knihovny OpenLayers, která byla využita k dědění při psaní kódu aplikace (viz kapitola 5.3). Parametry do této funkce jsou název rodičovské třídy a objekt s definicí nové třídy. Class podporuje i vícenásobnou dědičnost, takže rodičovských tříd v parametru této funkce může být i více. Stejným způsobem, jaký je uveden v ukázce C.3, (přes pomocný konstuktor) vytvoří novou třídu, které do prototype přiřadí všechny metody z rodičovských tříd a z objektu nově definované třídy. Na závěr vrátí nově vytvořenou třídu.

4.4.4.2

Události

Obecně, nejen v jazyce JavaScript, je používána vazba event-listener. Event, nebo-li událost, je vyvolávána producentem, který představuje určitá třída. Listener, nebo-li posluchač, je objekt, který jako reakci na danou událost provede specifickou akci. Příkladem může být v JavaScriptu zpracování callbacku onclick při události click. V jazyku JavaScript jsou již definované jisté events a k nim příslušné listenery. Kromě výše zmíněné interakce click-onclick, existují focus-onfocus, change-onchange, move-onmove a další. Ve frameworku OpenLayers jsou dále nadefinované například události activate a deactivate produkované třídou OpenLayers.Control. Tyto události jsou vyvolány při aktivaci či deaktivaci jakékoliv operace s mapou ovládané dědící třídou třídy OpenLayers.Control. Potomek OpenLayers.Control zpravidla produkuje i další události, jako například vertexmodified či featuremodified třídy OpenLayers.Control.ModifyFeature. Událost vertexmodified nastává při změně polohy lomového či virtuálního bodu objektu v mapě a událost featuremodified nastane při dokončení modifikace geometrie objektu.


31

Každý potomek třídy OpenLayers.Control má proměnnou eventListeners, což je objekt obsahující funkce stejných názvů, jako mají události produkované touto třídou. Při vzniku události se v metodě třídy, která dědí od třídy OpenLayers.Handler, volá funkce určitého potomka třídy OpenLayers.Control, která zavolá metodu triggerEvent() třídy OpenLayers.Events. Tato metoda má v parametru název dané události a jejím zavoláním se událost propaguje listenerům. Metoda triggerEvent() prochází listenery navázané k danému producentovi události a spouští kód definovaný v těle funkce stejného názvu jako má událost. Lze také vytvořit vlastní událost pouhým zavoláním funkce triggerEvent(), v jejímž argumentu bude název nové události. Dále je třeba nadefinovat zpracování události, jako funkci v objektu eventListeners s názvem odpovídajícím názvu nové události. Metoda triggerEvent() pak zavolá tuto funkci v objektu eventListeners.

4.5

REST

REST (Representational State Transfer) je architektonický styl navržený pro distribuované prostředí, tedy pro aplikace, kde části programu běží na různých strojích a pro svoji komunikaci využívají síť. Nejčastěji je používán ve spojitosti s protokolem HTTP. Text v této podkapitole byl čerpán ze zdrojů [29], [31].

4.5.1

Cíle REST architektury

Hlavním cílem této architektury je vytvořit jednotné aplikační rozhraní, které snadno přistupuje a manipuluje se zdroji (daty), zajistit škálovatelnost jednotlivých komunikujících komponent aplikace, zvýšit bezpečnost a snížit čas odezvy. Všechny zdroje, ke kterým aplikace přistupuje, jsou jednoznačně identifikovány pomocí URI (Uniform Resource Identifier – Jednotný identifikátor zdroje”) a lze s nimi manipulovat po” mocí čtyř základních metod. Tyto metody jsou označovány jako CRUD (Create-Read -UpdateDelete).

1. Create: Tato metoda slouží k vytvoření nového záznamu a v HTTP protokolu je reprezentována požadavkem POST. Tuto metodu je vhodné použít v případě, kdy při vytváření nového


32

záznamu neznáme předem jeho identifikátor. Metoda není idempotentní, což znamená, že po opakovaném provedení této operace se vždy vytvoří nový záznam. 2. Read: Metoda se používá k získání dat a v HTTP protokolu je reprezentována požadavkem GET. Tato metoda je idempotentní, což znamená, že několikanásobné provedení této operace má vždy stejný výsledek. 3. Update: Tato metoda se používá k vytvoření či změně záznamu a v HTTP protokolu je reprezentována požadavkem PUT. K použití této metody je třeba znát identifikátor záznamu. Metoda je idempotentní, takže po několikanásobném provedení zůstává výsledek vždy stejný. Pokud záznam se zadaným identifikátor není nalezen, je vytvořen nový záznam a při opětovném volání této metody pouze dochází k přepsání stávajícího záznamu. 4. Delete: Provedením této operace dochází ke smazání záznamu. Tato metoda je idempotentní, při opakovaném volání je již smazaný záznam nenalezen a k žádné další změně dat nedochází.

REST často používá pro datovou výměnu standardizované formáty jako JSON, XML, RSS aj. Rozšíření této architektury napomáhá technika AJAX. Spojení AJAXu a architektury REST poskytuje užitečné nástroje při programování webových aplikací.

4.5.2

Omezení REST architektury

Architektura REST definuje množinu omezení, která by navržená aplikace měla splňovat. V případě, že jsou dodržena všechna omezení, lze takovou aplikaci označit jako RESTful. Omezení jsou následující: 1. Client/server: Tato vlastnost rozděluje REST aplikaci na vrstvy, které spolu komunikují přes síť. 2. Bezestavovost (Stateless): Toto omezení zakazuje uchovávání si informací o stavu na serveru. Každý požadavek, který je na server poslán, musí obsahovat všechny potřebné informace k jeho vykonání. Odpověď serveru je ten samý požadavek vždy stejná. Velikost dat posílaných po síti se tímto podstatně zvětšuje. Toto omezení tedy například neumožňuje používat session.


33

3. Cache: Tato vlastnost slouží jako kompenzace k předchozímu omezení bezestavovosti. Jejím úkolem je snížit objem posílaných dat a zvýšit výkonnost. Odpovědi serveru lze uložit do cache a použít opakovaně. 4. Vrstevnatost (Layered System): Aplikace se může skládat z libovolného množství vrstev poskytujících služby za účelem zvýšení variabilnosti. Jednotlivé vrstvy komunikují pouze se sousedními vrstvami a ostatních si nejsou vědomy. 5. Code-On-Demand: Tento požadavek je nepovinný a umožňuje rozšíření funkcionality aplikace zasláním kódu spustitelného na klientské straně (například JavaScript nebo applet).

4.6

AJAX

AJAX (Asynchronous JavaScript and XML) je způsob využití již existujících technologií, které mění obsah částí webových stránek bez jejich znovunačtení. Mezi tyto technologie patří:

1. HTML a CSS - jazyky pro vytváření webových stránek 2. JavaScript - objektově orientovaný skriptovací jazyk, viz podkapitola 4.4.4 3. XMLHttpRequest - viz podkapitola 4.6.1

Výhody využití tohoto souboru technologií spočívá v možnosti vytvoření přívětivějších uživatelských rozhraní, kdy uživatel není zdržován překreslováním celé stránky a má pocit větší plynulosti práce. Dále se sníží zátěž na server, neboť ubývá nutnosti vygenerování znovu celé stránky. Na druhou stranu při nevhodném použití AJAXu a častém vytváření požadavků může dojít i ke zvýšení zátěži serveru. Další nevýhodou oproti klasickému znovunačtení stránky je pro uživatele nemožnost vrátit tlačítkem Zpět”změnu na stránce způsobenou AJAXem. ” Text v této podkapitole byl čerpán ze zdrojů [1], [25], [28].


4.6.1

34

XMLHttpRequest

Specifikace XMLHttpRequest definuje API, které poskytuje prostředky pro komunikaci mezi serverem a klientem (viz [22]). Tato specifikace je standardizována konsorciem W3C (World Wide Web Consortium), jehož členové vyvíjejí standardy pro webové služby. V kódu JavaScriptu lze vytvořit objekt třídy XMLHttpRequest, na který je možné zavolat metody pro zaslání požadavku na server. Parametrem metody open() lze specifikovat typ požadavku - GET, POST, PUT nebo DELETE, metodou send() lze poslat data na server. Data přenášená mezi serverem a klientem mohou být v různých typech formátů, například XML, JSON, HTML a dalších. Třída XMLHttpRequest definuje také metody pro zpracování odpovědi ze strany serveru. Metoda onreadystatechange() se vykoná při přijetí odpovědi a metodou status() lze zjistit návratový kód (viz následující podkapitola 4.6.2). S pomocí responseText() lze získat data zaslaná serverem.

4.6.2

Stavové kódy HTTP

Text v této podkapitole byl čerpán ze zdroje [21]. Server reaguje na požadavek klienta (Request) zasláním odpovědi (Response). Odpověď serveru obsahuje kromě hlaviček a zaslaných dat také stavový kód a stavové hlášení. Tento kód spolu se slovním popisem (hlášením) klientovi říká, zda se provedení požadavku zdařilo nebo ne. Kódy jsou podle velikosti uspořádány do kategorií znázorněných v tabulce pod tímto odstavcem. V článku [21] jsou také popsány jednotlivé návratové kódy. Zde však toto nebude rozepisováno. Kategorie

Rozsah stavových kódů

Popis

Informační

100 - 199

Zprávy definované konkrétní aplikací.

Úspěch

200 - 299

Požadavek byl úspěšně zpracován.

Přesměrování

300 - 399

Klient musí pro konečné zpracování požadavků vykonat určitou činnost. O této činnosti se uživatel nemusí dozvědět.

Chyba klienta

400 - 499

Problémy na straně klienta.

Chyba serveru

500 - 599

Problémy na straně serveru.


4.7

35

JSON a GeoJSON

V následujících podkapitolách jsou popsány textové formáty JSON a GeoJSON. Text v těchto podkapitolách byl čerpán ze zdrojů [27] a [7]. Ukázky zápisu dat v těchto formátech byly vytvořeny v online programu [8].

4.7.1

JSON

JSON (JavaScript Object Notation) je textový formát určený pro výměnu dat. Tento formát je ideální pro zápis kratších strukturovaných dat posílaných prostřednictvím internetu mezi klientem a serverem. Formát JSON je platným zápisem jazyka JavaScript, ale lze ho použít pro přenos dat v libovolném programovacím či skriptovacím jazyce. Výhodou tohoto formátu je i to, že je dobře čitelný pro člověka. Struktura zápisu formátu JSON odpovídá struktuře zápisu objektu v jazyce JavaScript, tj. pár { klíč”: hodnota}. Klíč” musí být vždy typu string a hodnota může být v ” ” následujících formátech:

1. string - uvozený dvojitými uvozovkami ”” 2. číslo - celočíselné nebo reálné s desetinnou tečkou, kladné či záporné, je možný i exponenciální tvar (1e10 ) 3. boolean 4. null 5. pole - setříděná kolekce hodnot ohraničená hranatými závorkami a oddělená čárkou ([hodnota1, hodnota2, . . .] ), hodnoty mohou být v libovolném z těchto 6 uvedených datových typů, což znamená, že lze vytvořit několikanásobně vnořenou strukturu 6. objekt - opět pár { klíč”: hodnota}, hodnoty mohou také být v libovolném z těchto 6 ” uvedených datových typů

Mezi jednotlivé páry lze vkládat bílé znaky (mezery nebo tabulátory). Na obrázku C.4 v příloze je uveden příklad zápisu dat ve formátu JSON.


4.7.2

36

GeoJSON

Formát GeoJSON vznikl jako rozšíření výše popsaného formátu JSON o zápis geometrie různých geometrických objektů či jejich souboru. Téměř každý objekt formátu GeoJSON má parametr type”. Tento parametr je typu string ” a jeho hodnoty mohou být buď některý z typů geometrie nebo Feature”nebo FeatureColle” ” ction”. Objekt typu FeatureCollection”vyjadřuje soubor geometrických objektů s popisnými vlast” nostmi. Tento objekt musí mít parametr features”, což je pole objektů typu Feature”. ” ” Objekt typu Feature”je geometrický objekt s popisnými vlastnostmi. Tento objekt má povinné ” parametry geometry”a properties”. Parametr geometry”je objekt typu geometrie nebo null. ” ” ” Člen properties”je opět objekt nebo null. ” GeoJSON podporuje následující typy geometrie:

1. Point”- bod ” 2. LineString”- lomená linie ” 3. Polygon”- mnohoúhelník ” 4. MultiPoint”- množina bodů ” 5. MultiLineString”- množina lomených čar ” 6. MultiPolygon”- množina polygonů ” 7. GeometryCollection”- množina různých geometrických objektů ” Každý objekt geometrie jiného typu než GeometryCollection”musí mít parametr coordi” ” nates”, což je pole, jehož struktura je závislá na typu geometrie. Každý bod v poli coor” dinates”je vyjádřen min 2 čísly ([x, y, (z)] / [zem. šířka, zem.délka, (nadm. výška)]). Geometrické objekty zapsané ve formátu GeoJSON mohou být doplněny i o pole 4 souřadnic vyjadřující minimální ohraničující obdélník ( bbox”) a o informace o souřadnicovém systému, v ” němž je poloha objektu definována. Souřadnicový systém je vyjádřen parametrem crs”. Pokud ” není hodnota tohoto parametru rovna null, je to objekt s parametry type”a properties”. ” ”


37

Hodnota parametru type”určuje způsob vyjádření souřadnicového systému. Pokud je například ” parametr type”rovný hodnotě name”, obsahuje parametr properties”objekt s parametrem ” ” ” name”, v němž je uložen kód souřadnicového systému. ” Na obrázku C.5 v příloze je ukázka dat zapsaných ve formátu GeoJSON.

4.8

NetBeans IDE

V průběhu implementace aplikace byl kód psán v opensource vývojovém prostředí NetBeans IDE. Toto prostředí je vytvořeno v programovacím jazyce Java a je primárně určeno pro vývoj v tomto jazyce. Podporuje ale také jiné platformy, jako PHP, JavaScript, C, C++ aj. NetBeans je možné používat v operačním systému Windows, Mac, Linux či Solaris. Základní verze NetBeans obsahuje pokročilý vícejazyčný editor, debugger a verzovací nástroj. Editor usnadňuje práci při psaní kódu jeho syntaktickým zvýrazněním, označením případných chyb a nabízením nápovědy při psaní. Užitečnou funkcí je tzv. refactoring, který automaticky aktualizuje kód celé aplikace při přejmenování určitého názvu funkce nebo při přesunutí třídy do jiného adresáře apod. Výhodné je také používat klávesovou zkratku Ctrl+i, která umožňuje kontextové vyhledávání v celém kódu, a dále funkci pro vyhledávání definic funkcí či tříd kliknutím se stisknutou klávesou Ctrl na určitý objekt třídy nebo volání funkce. Základní verzi je možné doplnit o různé moduly, které umožňují široké využití NetBeans v praxi. Text v této podkapitole byl čerpán ze zdroje [10]. Z těchto stránek je možné si zdarma stáhnout verzi prostředí NetBeans IDE.

4.9

Firebug

Při vývoji aplikace byl často využíván nástroj Firebug. Tento nástroj je doplněk do webového prohlížeče Mozilla Firefox, ale existují verze i pro jiné prohlížeče, jako Internet Explorer v. 6+, Opera, Safari a Chrome. Doplněk umožňuje analyzovat využití sítě, upravovat a ladit HTML a CSS kód, krokovat kód JavaScriptu za pomocí JavaScript debuggeru, vypisovat vlastnosti objektů JavaScriptu a jiné užitečné funkcionality.


38

Text v této podkapitole byl čerpán ze zdroje [5]. Z těchto stránek je možné si zdarma stáhnout verzi nástroje Firebug.

Kapitola 5. Implementace

39

5 Implementace

Na základě požadavků a návrhu byla vytvořena ukázková webová mapová aplikace, která umožňuje zobrazovat, vytvářet, editovat a mazat geoprostorová data. Do aplikace je možné se přihlásit, pokud má uživatel založený účet v databázi. Nepřihlášený uživatel má k dispozici pouze tzv. informativní funkce, nemá možnost zasahovat do databáze. Přihlášený uživatel do databáze zasahovat může, tj. může vytvářet nové objekty různých typů, editovat a mazat objekty přiřazené k jeho účtu. Více je o naimplementovaných funkcích přístupným uživatelům popsáno v podkapitole 5.5. Objekty zobrazené uživatelům v mapě na stránce aplikace mají definované geometrické i popisné vlastnosti a jsou uloženy v PostgreSQL databázi s knihovnou PostGIS. Databáze byla vytvořena se strukturou popsanou v podkapitole 3.5. K databázi je přistupováno pomocí metod serverové části aplikace napsané v jazyce PHP (viz podkapitola 5.1). Tato část aplikace komunikuje s klientskou částí, která je implementována v jazyce JavaScript a využívá knihovny Ext JS, GeoExt a OpenLayers. Tyto knihovny poskytly funkcionalitu pro práce s mapou na stránce aplikace. Některé funkcionality však v těchto knihovnách chyběly a byly pro tuto aplikaci dopsány (viz podkapitola 5.3). Komunikace mezi klientskou a serverovou stranou probíhá prostřednictvím HTTP protokolu pomocí metod definovaných architekturou REST (více o této problematice je popsáno v podkapitole 5.4). Na klientské straně se po zaslání požadavku na server a následném přijmutí odpovědi mění části stránky na základě technologie AJAX. Umístění, uspořádání a komunikace jednotlivých komponent aplikace je znázorněna na diagramu nasazení v obrázku 5.1. Serverová část aplikace spolu s frameworkem Nette v. 2.0.6 a PHP 5 je umístěna na webovém serveru Apache. Databáze PostgreSQL v. 9.1.6 a PostGIS v. 2.0.1 běží na databázovém serveru, který je s webovým serverem umístěn na stejném stroji s operačním systémem Ubuntu 12.04.1 LTS. Ostatní komponenty - klientská část aplikace a javascriptové knihovny OpenLayers v. 2.12, ExtJs v. 4.0.7, GeoExt v. 2.0 se spouští v


40

kterémkoli webovém prohlížeči nainstalovaném na osobním počítači uživatele aplikace.

Obrázek 5.1: Diagram nasazení

5.1

Implementace serverové části

Serverová část aplikace byla implementována v jazyce PHP s využitím frameworku Nette. Při implementaci serverové části aplikace byla dodržována architektura MVC (viz podkapitola 4.3.1). Ve vrstvě Controller byly vytvořeny třídy BasePresenter, HomepagePresenter a ErrorPresenter. Třída BasePresenter vytváří přihlašovací formulář a volá metodu login(). HomepagePresenter zpracovává požadavky ze strany klienta a volá metody třídy Model. ErrorPresenter se spolu s příslušnými šablonami vrstvy View stará o zobrazení chybových hlášek při výskytu chyby na serveru. Do vrstvy View patří společná šablona layout.latte, dále šablona default.latte příslušící k default akci HomepagePresenteru a šablony vykreslující chybové hlášky na stránce. Kód souboru default.latte definuje globální proměnné pro JavaScript, připravuje prázdné tagy div k naplnění


41

JavaScriptem (div pro mapu, formuláře, tabulku apod.) a je předán v proměnné content do šablony layout.latte. V souboru layout.latte je přidáno vykreslení přihlašovacího formuláře a celkový obsah souboru je zobrazen na stránce. Vrstva Model obsahuje třídu Model a Authenticator. S pomocí metod třídy Model je přistupováno do databáze, provádějí se zde výběry, vkládání nových záznamů, úprava záznamů a mazání. Metody třídy Authenticator jsou volány při pokusu o přihlášení (po zavolání funkce login() v BasePresenteru). Tyto metody kontrolují zadané přihlašovací údaje uživatele se záznamy v databázi. V případě, že údaje souhlasí, vytvoří se nová instance třídy Identity, Nette framework nastaví proměnné reprezentujícího uživatele stav přihlášen a vygeneruje nové session-id (viz vysvětlení v podkapitole 2.3.2). Dále byla vytvořena třída ConvertObjects se statickými metodami převádějící vstupní data z formátu pole do formátu GeoJSON a zpět. Dokumentace kódu serverové části aplikace s popisem jednotlivých metod výše zmíněných tříd je umístěna v digitálních přílohách této práce. Nezbytnou součástí serverové části aplikace jsou soubory bootstrap.php, config.neon, index.php a další. Soubor index.php je spouštěcí soubor celé aplikace a je v něm definována cesta do adresáře /app s kódem aplikace a do adresáře /libs s frameworkem Nette. Dále je řízení předáno zaváděcímu souboru bootstrap.php. V tomto souboru je načten framework Nette, soubor config.neon, zdrojové kódy aplikace a naplněn systémový kontejner, který obsahuje všechny služby a parametry potřebné pro běh aplikace. Dále jsou provedeny další nezbytné konfigurace, například nastavení výchozí akce presenteru či zobrazování chyb, a nakonec je aplikace spuštěna. V souboru config.neon, který je načten v bootstrap.php, jsou nastaveny přístupové údaje do databáze, jako server a port, kde databáze běží, uživatelské jméno a heslo.

5.2

Implementace klientské části

Klientská část aplikace byla naimplementována v jazyce JavaScript s využitím knihoven Ext JS, GeoExt a OpenLayers. S pomocí funkcionalit nabídnutých těmito knihovnami byly vytvořeny funkce pro různé operace v mapě, jako odečtení souřadnic bodu, měření délky, plochy, nakreslení nového objektu, editace geometrie objektu, smazání objektu z mapy aj. Tyto funkce byly přiřazeny k tlačítkům v mapovém panelu, aby byly ovladatelné uživatelem aplikace. Mapový


42

panel byl vložen do tagu div v šabloně default.latte (viz předchozí podkapitola 5.1). Dokumentace kódu klientské části aplikace je umístěna v digitálních přílohách této práce. Kód klientské části aplikace byl sestavován ve vývojovém prostředí NetBeans IDE (viz podkapitola 4.8) pomocí nástroje Apache Ant. Apache Ant je soubor nástrojů pro příkazovou řádku, obecně používaný pro sestavování aplikací. Pro tento nástroj byl napsán konfigurační soubor v jazyce XML build.xml. Při sestavování je zdrojový kód klientské části aplikace rozdělený v několika souborech spojen do jednoho souboru client-1.0.0b.js. Následně je tento soubor pomocí programu yuicompressor-2.4.7.jar (viz [26]) minimalizován optimalizací bílých znaků a odstraněním komentářů pro účely zmenšení objemu dat stahovaných ke klientovi. Minimalizovaná verze client-1.0.0b.min.js je importována do šablony default.latte příslušící HomepagePresenteru.

5.3

Rozšíření funkcionality OpenLayers

Pro běh této webové aplikace bylo využito zejména tříd knihovny OpenLayers. Některé detailnější funkcionality, které jsou nyní využívány, však v knihovně chyběly a bylo je třeba pro aplikaci doplnit. Jedná se o doplnění:

1. snappingu na středy hran 2. snappingu ve funkcích v menu Měření” ” 3. nastavení události startDraw”při kreslení linie či polygonu ”

5.3.1

Midpoint snapping

Knihovna OpenLayers podporuje dochytávání při kreslení na lomové body, samostatné body a na celé hrany (každý bod ležící na hraně) ostatních prvků. Tato funkce se dá aktivovat pomocí OpenLayers.Control.Snapping. V této třídě lze nastavit toleranci, tzn. maximální poloměr okolí bodu, v němž se již dá na tento bod dochytit, cílovou vrstvu nebo více vrstev, na jejichž objekty se bude dát dochytit, prioritu danou pořadím typů cílových bodů (lomové body / samostatné body / body na hraně) aj. Rozšíření této funkcionality spočívalo v zavedení možnosti dochytávání i na středy hran objektů. To bylo provedeno vytvořením nové třídy MySnapping, která dědí z třídy Open-


43

Layers.Control.Snapping. Dědění v knihovně OpenLayers je vyřešeno třídou OpenLayers.Class (vysvětlení implementace dědičnosti v jazyce JavaScript je v podkapitole 4.4.4) a syntaxe pro zavedení dědičnosti je naznačena pod tímto odstavcem. Na místě 3 teček je ve třídě umístěn kód, který přetěžuje metody definované v OpenLayers.Control.Snapping. MySnapping = OpenLayers.Class(OpenLayers.Control.Snapping, { ... });

V nové třídě MySnapping byl doplněn kód pro výpočet polohy nejbližšího bodu ležícího na středu hrany k aktuální poloze ukazatele myši. Dále byl midpoint zařazen do pořadí určujícího prioritu typů cílových bodů na pozici mezi lomové body a hrany. Výsledné pořadí typů bodů je tedy následující:

1. samostatně stojící body (nejvyšší priorita) 2. lomové body 3. středy hrany 4. všechny body na hraně (nejnižší priorita)

5.3.2

Snapping při měření

Další rozšíření se opět týká snappingu. Knihovna OpenLayers podporuje snapping pouze při akci kreslení (ovládané třídou OpenLayers.Control.DrawFeature). Toto rozšíření umožňuje využívat dochytávání i při funkcích měření v mapě, což jsou v této aplikaci funkce spustitelné přes menu Měření”- Souřadnice”, Měření délky”, Měření plochy”. Všechny tyto funkce zajišťuje kód ” ” ” ” třídy OpenLayers.Control.Measure. Výpočet cílových bodů při snappingu je aktivován v těle metody onSketchModified() třídy OpenLayers.Control.Snapping. Tato metoda je spouštěna listenerem, který reaguje na událost sketchmodified (vysvětlení vazby events a listeners bylo provedeno v podkapitole 4.4.4.2). Událost sketchmodified je defaultně v OpenLayers produkována třídou OpenLayers.Control. DrawFeature při kreslení prvků v mapě.


44

Realizace rozšíření funkcionality snappingu i na měření prakticky znamenala zavedení vytvoření události sketchmodified i ve třídě ovládájící kreslení pomocných geometrických objektů při měření v mapě (v OpenLayers.Control.Measure). Jedná se o kreslení pomocného bodu ve funkci Souřadnice”, kreslení pomocné linie ve funkci Měření délky”či kreslení pomocného polygonu ” ” ve funkci Měření plochy”. ” Byla tedy vytvořena nová třída MyMeasure, která dědí ze třídy OpenLayers.Control.Measure. V nové třídě byla přetížena metoda initalize(), v níž byla definována funkce modify. Funkce modify volá metodu triggerEvent() s parametrem

”

sketchmodified”, čímž aktivuje listenery

události sketchmodified. Funkce modify je volána v příslušném handleru, OpenLayers.Handler.Point, OpenLayers.Handler. Path či OpenLayers.Handler.Polygon, při kreslení objektu.

5.3.3

Událost startDraw

Při aktivované funkci kreslení linie nebo kreslení polygonu se v této aplikaci po nadefinování prvního lomového bodu zpřístupní tlačítka pro ovládání kresby ( Zpět”, Znovu”, Ukonči”, ” ” ” Zruš”). K tomuto bylo zapotřebí zavést novou událost, která nastane v okamžiku vložení ” prvního bodu daného geometrického prvku. Tato událost byla nazvána startDraw. K tomuto účelu byla vytvořena nová třída MyDrawFeature, která dědí z OpenLayers.Control. DrawFeature, a dále třídy MyHandlerPath a MyHandlerPolygon, které dědí z OpenLayers. Handler.Path a OpenLayers.Handler.Polygon. V kódu třídy MyDrawFeature byla přetížena metoda initalize(), kde byla definována funkce firstPoint(). Funkce firstPoint() volá metodu triggerEvent() s parametrem startDraw”, čímž ” aktivuje listenery události startDraw. V metodě addPoint() tříd MyHandlerPath a MyHandlerPolygon je funkce firstPoint() zavolána v případě, že je vložený bod do dané geometrie první v pořadí. V objektu eventListeners třídy MyDrawFeature byla definována funkce s názvem startDraw(), která v reakci na událost startDraw vykoná zpřístupnění ovládajících tlačítek.


5.4

45

Použití REST

Dle návrhu (viz podkapitola 3.2) byla v aplikaci použita architektura REST. Ukázalo se však, že není vhodné založit celou aplikaci na této architektuře a bylo by zároveň velmi problematické vytvořit aplikaci tak, aby ji bylo možné označit jako RESTful. Jak bylo popsáno v podkapitole 4.5.2, je jedním z omezení RESTu vyloučení použití session. Zde použitý PHP framework Nette však session využívá a navíc v této aplikaci je přímo používáno session-id vygenerované při přihlášení uživatele. Z cíle vytvořit RESTful aplikaci bylo tedy upuštěno, nicméně aplikace využívá architekturu REST, jak je popsána v podkapitole ?? a pomocí Nette frameworku bylo implentováno zpracování čtyř základních metod CRUD (viz podkapitola 4.5.1). S vyjímkou akce přihlášení a odhlášení (kdy se načítá celá stránka) probíhá komunikace mezi serverem a klientem prostřednictvím protokolu HTTP přes rozhraní XMLHttpRequest (viz podkapitola 4.6.1) a obsah stránky se mění na základě AJAXu (viz podkapitola 4.6). V závislosti na určité akci uživatele je vyvolán požadavek (Request) na server prostřednictvím určité metody. Jedná se buď o metodu GET (dle definice RESTu Read ), POST (dle definice RESTu Create), PUT (dle definice RESTu Update) nebo DELETE (dle definice RESTu taktéž Delete). Server tento požadavek přijme, zpracuje, podle typu metody vyvolá určitou akci a zašle odpověď (Response) zpět klientovi. Klient odpověď zpracuje bez nutnosti obnovení celé stránky. Na obrázku C.6 v příloze je ukázka kódu JavaScriptu, jehož výsledkem je Request na server metodou PUT. Objekt XMLHttpRequest nefunguje ve všech prohlížečích stejným způsobem a jeho vytvoření se různí. V ukázkovém kódu jsou uvedeny dva možné způsoby vytvoření tohoto objektu, které jsou použitelné v prohlížečích Internet Explorer od verze 5, Mozilla Firefox, Google Chrome, Opera, Safari. Po vytvoření objektu se zavolá metoda open() s parametry: typ operace (v tomto případě PUT), URL adresa a boolean parametr označující, zda jde o asynchronní (TRUE) či synchronní (FALSE) požadavek. Dále se definují hlavičky a nakonec se metodou send() zašlou data ve formátu JSON. Metoda send() se používá pouze v případě užití operace PUT či POST, při ostatních operacích není třeba ji volat. Na serveru je pak v závislosti na typu Requestu volána určitá funkce, s pomocí které se přistupuje do databáze. Na obrázku C.7 v příloze je ukázka kódu třídy HomepagePresenter, který odchytává”zaslané Requesty. Po provedení určité akce na straně serveru, zašle server klien” tovi odpověď (Response). Kromě návratového kódu (viz podkapitola 4.6.2) lze zaslat i data (Nette metodou sendResponse()), například ve formátu JSON. Klient tuto odpověď přijme,


46

data zpracuje a obvykle na základě tohoto změní část obsahu stránky (například vytvoří formulář).

5.5

Popis aplikace z pohledu uživatele

V této podkapitole je popsána funkčnost aplikace z pohledu uživatele, tj. jak vypadá uživatelské rozhraní, jaké funkce má uživatel přístupné, co mu tyto funkce umožňují apod. Podrobněji, z hlediska celého systému, jsou vybrané operace popsány v kapitole 5.6. Po zadání URL adresy umístění aplikace do webového prohlížeče se uživateli zobrazí stránka s mapovým panelem a přihlašovacím panelem (viz obrázek D.1 v příloze). Mapa zobrazuje dvě vrstvy - vektorovou vrstvu objektů a podkladovou vrstvu ortofota, získaného přes WMS. Ve vektorové vrstvě jsou již uloženy ukázkové objekty s nadefinovanými popisnými atributy. Mapa je nakonfigurována v souřadnicovém systému S-JTSK East North (EPSG:102067). V návrhu aplikace byly definovány dvě uživatelské role - Guest a User. Nepřihlášený uživatel má přiřazenou roli Guest. Tomuto uživateli je přístupná pouze část z celkové funkcionality aplikace. Pokud má uživatel založený účet v databázi, má možnost se přihlásit. Po úspěšném přihlášení se z uživatele stane User a zpřístupní se mu celá funkcionalita aplikace. Správa uživatelských účtů prostřednictvím webové aplikace nebyla předmětem této diplomové práce, takže uživatel bez založeného účtu nemá prozatím možnost si jej přes aplikaci vytvořit. Zároveň uživatel s již vytvořeným účtem nemá možnost upravovat své osobní údaje či měnit heslo. Doplnění těchto funkcionalit je jedním z návrhů na rozšíření stávající aplikace. Další možností rozšíření by mohlo být vytvoření rozhraní pro novou roli Administrator, který by měl kontrolu nad uživatelskými účty, mohl by přidávat, měnit či mazat typy objektů nebo vlastnosti objektů. Ve stávající aplikaci toto zatím není možné a takovéto změny lze provést pouze přímo v databázi například prostřednictvím programu pgAdmin. Následující podkapitoly popisují funkcionalitu aplikace přístupnou nepřihlášenému uživateli (roli Guest) a rozšířenou funkcionalitu přístupnou přihlášenému uživateli (roli User ).

5.5.1

Nepřihlášený uživatel

Nepřihlášený uživatel má mapu přístupnou pro základní operace, jako je posun a zoom prostřednictvím myši i pomocí ovládacích prvků v levé části mapy. Dále má možnost zobrazovat a


47

skrývat mapové vrstvy (vektorovou vrstvu objektů a podkladovou vrstvu ortofota) pomocí zaškrtávacích políček v ovládacím panelu v pravé části mapy. Tento panel je defaultně skrytý a dá se zobrazit kliknutím na +”. Uživatel má také přístupná tlačítka a roletová menu v mapovém ” panelu. Funkčnost jednotlivých prvků v panelu je popsána v následujících podkapitolách.

5.5.1.1

Posun

Toto tlačítko má funkci spíše deaktivující, vypíná všechny ostatní spuštěné akce. Uživatel má pak pouze možnost pohybu s mapou.

5.5.1.2

Info

Tlačítko Info”zapíná funkci, která vypisuje všechny popisné atributy vybraného objektu. ” Objekt se vybere kliknutím a jeho vlastnosti se vypíší do tabulky napravo od mapového pole spolu s názvem typu daného objektu (viz obrázek D.2 v příloze). Kliknutím na jiný objekt v mapě nebo mimo kterýkoliv objekt či vypnutím celé této funkce (zapnutím jiné) se zruší výběr původního objektu a tabulka s popisnými atributy zmizí.

5.5.1.3

Měření

Toto roletové menu sdružuje funkce, kterými se dá měřit v mapě.

1. Souřadnice: Toto tlačítko zapíná funkci pro odečtení polohy bodu v mapě. Po kliknutí do mapy se objeví okénko s vypsanými souřadnicemi zadaného bodu v systému S-JTSK se zápornými hodnotami. 2. Měření délky: Funkcí Měření délky”lze zjistit přímá vzdálenost mezi body v mapě. Tato vzdálenost ” se získává ze souřadnic zadaných bodů. V případě, že uživatel zadá více než dva body, aplikace mu vrátí součet dílčích vzdáleností mezi dvěma sousedními body. Definování zájmových bodů (lomových bodů měřící lomené čáry) se ukončí dvojklikem. Po tomto ukončení se uživateli zobrazí okénko s výslednou vzdáleností v metrech.


48

3. Měření plochy: Měření plochy”funguje obdobně jako předchozí funkce Měření délky”. Uživatel postupně ” ” zadává vrcholy měřící plochy, tuto definici ukončí dvojklikem a poté se mu zobrazí okénko s výslednou plochou v m2 (viz obrázek D.3 v příloze).

Všechny tyto funkce se deaktivují zapnutím funkce jiné.

5.5.1.4

Snap

Položky v tomto menu ovládají snapping při aktivované některé z funkcí v menu Měření”nebo ” Editace objektů”(zobrazené po přihlášení uživatele). Menu obsahuje tři zaškrtávací políčka a ” pole pro zadání čísla s popisem Tolerance”. Zaškrtávací políčka umožňují navolit dochytávání ” se na:

1. lomové body liniových či plošných objektů nebo na samostatné bodové objekty 2. středy hran liniových či plošných objektů nebo na samostatné bodové objekty 3. kterýkoliv bod ležící na hraně liniových či plošných objektů nebo na samostatné bodové objekty

V poli Tolerance”lze nadefinovat poloměr okolí bodu v pixelech, v němž se již bude ukazatel ” na tento bod dochytávat. Do tohoto pole lze zadat pouze celé kladné číslo nebo 0. V případě, že uživatel zadá hodnotu tolerance rovnu 0, snapping nebude aktivní. Defaultně je snapping nastavený na toleranci rovnu 10px a dochytávání se na lomové body, středy hran i celé hrany. Funkce snappingu se nedá deaktivovat aktivací jiné funkce, zůstává stále aktivní. Dochytávání se dá zrušit pouze odškrtnutím všech zaškrtávacích políček nebo nastavením tolerance na hodnotu 0.

5.5.1.5

Přihlášení

Nepřihlášený uživatel se založeným účtem se může prostřednictvím přihlašovacího formuláře v horní části stránky přihlásit. Zadané přihlašovací údaje se porovnávají se záznamy v databázi. V případě, že přihlašovací jméno i hash hesla odpovídají záznamu v databázi, je uživatel přihlášen, čímž se změní role z Guest na User a uživateli se zpřístupní další funkce. V případě, že jméno


49

a heslo nesouhlasí se záznamem v databázi, k přihlášení nedojde a uživatel je upozorněn na nesprávně vyplněné přihlašovací údaje.

5.5.2

Přihlášený uživatel

Po úspěšném přihlášení uživatele se menu mapového panelu rozšíří o roletové menu Editace ” objektů”a tlačítka Zpět”, Znovu”, Ukonči”a Zruš”, která jsou však momentálně neaktivní. ” ” ” ” Přihlašovací formulář se nahradí tlačítkem Odhlásit se”. Zároveň objekty, jejichž vlastníkem je ” právě přihlášený uživatel, se zvýrazní (zvětší se šířka obvodové linie objektu). Toto zvýraznění je pro uživatele signálem, že je daný objekt přístupný editaci a mazání. Roletové menu Editace objektů”obsahuje položky reprezentující funkce popsané v následu” jících podkapitolách. Pro všechny níže popsané funkce související s editací objektů platí, že se deaktivují aktivací funkce jiné.

5.5.2.1

Kreslení prvků

Prvky tohoto menu tvoří názvy všech typů objektů, uložených v databázi. Uživatel má možnost si vybrat jeden z typů objektu, nakreslit ho do mapy (viz obrázek D.4 v příloze) a vzápětí nadefinovat jeho popisné vlastnosti. Podle toho, zda si vybral bodový, liniový či plošný objekt, se zapne příslušná kreslící funkce. V případě, že si vybral liniový či plošný prvek, zpřístupní se po definování prvního vrcholu tlačítka Zpět”, Znovu”, Ukonči”a Zruš”. Tlačítka Zpět”a Znovu”ovládají přidávání a ” ” ” ” ” ” odebírání lomových bodů objektu po dobu kreslení. Stejnou funkci plní i klávesové zkratky Ctrl+Z a Ctrl+Y. Tlačítko Ukonči”ukončí kreslení, zobrazí daný objekt v mapě se správnou ” barvou dle definice v databázi a zpřístupní formulář pro vyplnění popisných atributů. Stejnou funkci jako toto tlačítko má i dvojklik. Poslední tlačítko Zruš”zruší kreslení objektu (objekt se ” nevytvoří). Stejnou funkci plní i stisknutí klávesy Esc. Po dobu kreslení lze využít i snapping (viz podkapitola 5.5.1), ne však k uchycení na ten samý objekt, nebo lze polohu bodů definovat zadáním souřadnic do textových polí po pravé straně mapového pole (viz obrázek D.5 v příloze). Souřadnice musí být v systému S-JTSK, záporné a zadaný bod musí ležet na území ČR. Po nakreslení objektu se tlačítka Zpět”, Znovu”, Ukonči”a Zruš”opět zneaktivní. ” ” ” ” Dále má uživatel možnost vyplnit hodnoty popisných atributů daného objektu do formuláře (viz obrázek D.6 v příloze). Nabízí se vždy ty vlastnosti, které má k sobě přiřazen daný typ


50

objektu. Uživatel musí vyplnit údaje, které jsou povinné, což je ke každé vlastnosti nadefinováno v databázi. Pokud tak neučiní, aplikace nedovolí daný objekt uložit do databáze. Nepovinné údaje mohou zůstat nevyplněny. V případě, že uživatel správně vyplnil předepsané vlastnosti, odešlou se po kliknutí na tlačítko Odeslat”geometrické i popisné údaje o objektu na server a ” objekt se uloží do databáze. Když však uživatel klikne na tlačítko Zrušit”, nakreslený objekt ” se smaže a formulář zmizí. V případě, že by uživatel neklikl ani na jedno z tlačítek a snažil se například o vytvoření dalšího objektu nebo by zapnul jinou funkci, aplikace se ho zeptá, co chce s nakresleným objektem provést. Uživatel může buď zadat, že chce objekt zrušit, v tom případě ho aplikace smaže z mapy a dovolí uživateli pokračovat v činnosti, nebo že chce objekt uložit do databáze, což v případě správně vyplněných údajů ve formuláři aplikace provede. V případě chybně vyplněných údajů ve formuláři, aplikace uživatele na tuto skutečnost upozorní a objekt do databáze neuloží, smaže ho a uživatel je nucen případně daný objekt vytvořit znovu.

5.5.2.2

Editace prvků

Po aktivaci funkce Editovat prvek”může uživatel kliknout na příslušný objekt a tím zahájit ” jeho editaci. Uživatel má možnost editovat pouze ty objekty, jejichž je vlastníkem, tzn. které dříve sám vytvořil. Takové objekty jsou pro názornost zvýrazněny v mapě tučně. Kdyby se uživatel pokusil editovat jiný objekt, než ten, který je jeho, byl by na tuto skutečnost upozorněn a aplikace by mu to nepovolila. Dále by mu nebyla editace povolena pokud by byl objekt právě uzamknut (viz podkapitola 2.3.2). V případě, že se uživatel rozhodne editovat svůj a odemknutý objekt, je editace zahájena. Po zahájení editace se daný objekt zvýrazní, zpřístupní se jeho lomové body a tzv. virtuální ” body”(body v polovině hran) modifikaci a do formuláře se vypíší popisné vlastnosti objektu s vyplněnými hodnotami. V této aplikaci je možné modifikovat geometrii objektu pouze změnou polohy jednotlivých lomových bodů nebo jejich smazáním nebo přidáním nového lomového bodu. Dalším námětem na rozšíření stávající aplikace je možnost modifikace posunutím celého objektu nebo jeho otočením atd. Lomový bod lze smazat tak, že ho nejprve uživatel identifikuje kliknutím a následně ho klávesou Delete smaže. Přidání lomového se provede vytažením virtuálního bodu”a jeho umístěním na ” požadovanou polohu. Z takovéhoto bodu se následně stane bod lomový a vytvoří se dva nové


51

virtuální body”(viz obrázek D.7 v příloze). Stávající lomové body i virtuální body lze tažením ” posouvat s využitím snappingu (viz podkapitola 5.5.1). Snapping však nelze použít k uchycení na ten samý objekt. Zároveň s editací geometrie může uživatel upravovat i popisné informace ve formuláři. Princip je stejný jako v případě vytvoření nového objektu. Opět se kontroluje, zda uživatel vyplnil povinné údaje a zda je vyplnil správně. V případě správně vyplněného formuláře lze po kliknutí na tlačítko Odeslat”uložit provedené změny do databáze. Zrušení změn se provede kliknutím ” na Zrušit”. V případě, že by uživatel neklikl ani na jedno z tlačítek, aplikace by se ho na ” uložení či zrušení změn zeptala sama, jako tomu je u funkce kreslení.

5.5.2.3

Rušení prvků

Tato funkce provádí mazání objektů z mapy i z databáze. Smazat může uživatel pouze svůj objekt a také objekt, který není právě uzamčen (viz podkapitola 2.3.2). V případě, že jsou obě tyto podmínky splněny, a uživatel v dialogu potvrdí, že chce Opravdu objekt smazat”, je ” objekt následně vymazán z databáze (viz obrázek D.8 v příloze).

5.5.2.4

Odhlášení

Přihlášený uživatel má samozřejmě možnost se zase odhlásit kliknutím na tlačítko Odhlásit se”. ” Pokud toto provede, roletové menu Editace objektů”a tlačítka Zpět”, Znovu”, Ukonči”a ” ” ” ” Zruš”zmizí a zároveň se zruší zvýraznění všech objektů. ”

5.6

Popis aplikace z hlediska systému

V této podkapitole jsou podrobněji popsány některé vybrané funkce aplikace. Je zde vysvětlena celá sekvence prováděných operací, komunikace mezi klientem a serverem, formát posílaných dat apod.

5.6.1

Načtení stránky, přihlášení uživatele

Diagramy B.2 a B.1 v příloze popisují akci načtení stránky webové aplikace a přihlášení uživatele. Tyto dvě akce jsou zde uvedeny najednou z toho důvodu, že na sebe přímo navazují.


52

Po přihlášení či odhlášení uživatele totiž dochází ke znovunačtení stránky webové aplikace, přičemž se mění množství předávaných dat a zobrazení mapového panelu na stránce. Po přijmutí žádosti k obnovení stránky dochází na straně serveru k požadavku na výběr dat z databáze. Do atributu value”se uloží hodnota vlastnosti objektu (value int / value double / ” value date / value char / value text) z tabulky VALUES nebo název vybrané hodnoty z číselníku z tabulky SELECT VAL. Dále se do atributu property”zapíše název vlastnosti objektu ” a k ní informace, zda je pro uživatele povinná nebo ne. Pro klientskou stranu jsou také důležité údaje jako id objektu, jeho typ, barva zobrazení (atribut color z tabulky TYPES OBJ ) a nakonec atribut editable”. Tento atribut je rovný buď 0 nebo 1. V případě, že k aplikaci není ” daný uživatel přihlášen, je atribut editable”u každého objektu rovný 0. Přihlášenému uživateli ” se k objektům, které jsou přiřazeny jeho účtu, nastavuje tento atribut rovný 1, ostatní mají hodnotu 0. Dále se provádí změna v tabulce USERS k danému přihlášenému uživateli, kde se nastavuje čas time check, což je čas zjištění stavu objektů v databázi, na aktuální čas. Následně se v tabulce DELETED OBJ promazávají staré záznamy, tzn. že se smažou záznamy k těm objektům, které byly z tabulky OBJECTS smazány dříve, než jaký je minimální čas aktualizace v tabulce USERS. Takže je zajištěno, že se v databázi nebudou hromadit nepotřebná data. Výběr dat se následně převádí do formátu GeoJSON a takto se posílá klientské straně. Údaje v něm uložené jsou potřebné pro způsob zobrazení jednotlivých objektů, pro zobrazení informací o objektech a pro ovládání jejich editace. Nastavují se jako atributy proměnným JavaScriptu reprezentujícím jednotlivé objekty. V případě, že je uživatel přihlášen, dochází kromě výběru předchozího souboru dat i k výběru všech typů objektů. Na základě těchto informací je následně na klientské straně vytvořeno podmenu Kreslení prvků”v menu Editace objektů”. ” ”

5.6.2

Vytvoření nového objektu

Přihlášený uživatel má možnost nakreslit, popsat a uložit do databáze nový objekt. Na výběr má z typů objektů nadefinovaných v databázové tabulce TYPES OBJ. U každého takovéhoto typu objektu se specifikováno, zda se jedná o bodový, liniový či plošný objekt atributem geom type. Podle toho se volá určitá kreslící funkce (třída knihovny OpenLayers). Uživatel může objekt nakreslit s využitím snappingu, případě může vložit bod po nadefinování


53

jeho souřadnic v S-JTSK v textových polích vedle mapového pole. Tyto souřadnice musí být záporné a jejich rozsah je omezen na území ČR. Rozsah se kontroluje pomocí funkce containsPoint() knihovny OpenLayers, která se spouští nad polygonem ČR. Polygon byl vytvořen vektorizací podkladové mapy v této aplikaci a následně byl uložen do formátu GeoJSON. Soubor s takto nadefinovanou geometrií se načítá spolu se zdrojovými kódy aplikace. Po nadefinování geometrie se kontroluje její validita, konkrétně, v případě polygonu, se ověřuje, zda má minimálně tři body. OpenLayers sice uložení polygonu pouze se dvěma vrcholy umožňuje, ale PostGIS nikoliv. Pokud je tedy nadefinovaná geometrie validní, zašle se GET-Request na server, kde se provede výběr všech vlastností přiřazených danému typu objektu z databáze. Každá vlastnost obsahuje kromě svého názvu i údaj o datovém typu své hodnoty ( int”/ double”/ bool”/ char”/ ” ” ” ” text”/ date”/ select”) a informaci, zda je povinná nebo ne. Pokud má určitá vlastnost ” ” ” objektu hodnotu typu select”, jedná se o vlastnost, která má své potenciální hodnoty uloženy ” v číselníku (tabulce SELECT VAL). Tyto hodnoty se rovněž vyberou z databáze. Všechny tyto informace slouží k vytvoření a naplnění formulářových prvků na klientské straně pro zadání popisných vlastností objektu. Dále následuje série tří přístupů do databáze, kdy se vybírají data o těch objektech, které byly buď změněny nebo smazány od doby poslední kontroly uživatele. Porovnává se čas kontroly (time check ) v tabulce USERS, čas provedení změny objektů (time update) v tabulce OBJECTS a čas smazání objektů (time del ) v tabulce DELETED OBJ. Nakonec se nastaví čas kontroly (time check ) na aktuální. Na klientskou stranu se následně zašlou informace o vlastnostech objektu a případné změněné objekty či id smazaných objektů. Klient zaktualizuje objekty zobrazené v mapě, tj. změněné objekty nahradí zaslanými daty a smazané objekty podle atributu id smaže také v mapě. Potom se vytvoří a naplní formulář pro zadání popisných informací k objektu. Samotný formulář je objekt třídy Form knihovny Ext Js. Při vytváření formuláře jsou definovány pravidla k jeho vyplnění a třída Form se pak sama stará o kontrolu validity formuláře. Validní vyplněné hodnoty formuláře jsou po kliknutí na tlačítko Odeslat”spolu s geometrií ” objektu převedeny do formátu, který je v diagramech v přílohách . . . i dále v textu označován jako MyJSON”. Text v tomto formátu vznikne uložením geometrie do WKT (viz podkapi” tola 4.1.1), která je vložena spolu s popisnými atributy objektu do formátu JSON. Výhoda takto uložených dat spočívá ve snadnějším vložení do databáze. Text je totiž po odeslání


54

na server (POST-Request) převeden do pole (PHP funkcí json decode()), přičemž geometrie zůstává nadále ve formátu WKT jako jeden z prvků pole. Po menších úpravách lze pak celé pole vložit do databáze pomocí třídy Database frameworku Nette. PostGIS s knihovnou JSON-C podporuje také zápis geometrie do databáze přímo ve formátu GeoJSON. Vložení geometrie ve formátu WKT je však možné už v základní verzi PostGISu. Na straně serveru aplikace znovu kontroluje, zda je uživatel přihlášen. Toto je prováděno z toho důvodu, protože je teoreticky možné, že by uživatel aplikace upravil ve svém počítači kód JavaScriptu tak, aby omezení na klientské straně obešel. Do kódu na straně serveru však nemá možnost zasahovat. V případě, že by se při kontrole zjistilo, že uživatel přihlášen není, nebyl by mu přístup do databáze povolen. Po kladně proběhnuté kontrole přihlášení přistupuje aplikace do databáze a provádí INSERT do tabulky OBJECTS a VALUES a objektu se nastaví čas vložení i provedení změny (time insert i time update). Následně opět dochází ke kontrole změn a případném vybrání dat o neaktuálních objektech z databáze. Nakonec se opět nastaví čas kontroly na aktuální. Klientovi jsou zpět zaslány id nově vloženého objektu a hodnot jeho vlastností, aby byly doplněny data k danému objektu v proměnné na klientské straně, a také případná změněná data, která jsou u klienta v mapě zaktualizována. Po této události je akce vytvoření nového objektu dokončena. Uživatel má dále možnost vytvářet další objekty. V příloze B.3 je uložen diagram popisující celou akci vytvoření nového objektu.

5.6.3

Editace objektu

Přihlášenému uživateli je dále přístupná funkce Editace prvků”. Každému uživateli jsou k ” úpravě dostupné pouze ty objekty, které jsou v databázi přiřazené k jeho účtu, tzn. objekty, které dříve vytvořil. Toto se kontroluje podle atributu

editable”v proměnné JavaScriptu ” reprezentující daný objekt. V případě, že si uživatel k editaci vybral svůj objekt, přistupuje se k další kontrole. Jedná se kontrolu zámku, což značí, zda daný objekt právě také někdo edituje či ne (viz podkapitola 2.3.2). Kontrola zámku probíhá následovně: Zašle se GET-Request na server, kde se provede dotaz do databáze, a klientské straně se pošle odpověď, zda je danému objektu nastaven atribut locked na TRUE či FALSE. V případě, že by se při kontrole zámku došlo k závěru, že je objekt uzamknut, nebyla by danému uživateli editace povolena. V opačném případě je vzápětí objekt


55

uzamknut nastavením atributu locked na TRUE, locks id na session-id a lock time na aktuální čas s přesností na vteřiny. Session-id je jedinečný vygenerovaný klíč frameworkem Nette při přihlášení uživatele do aplikace. Při uzamykání objektů se pro ověření totožnosti uživatele používá tato 26-znaková sekvence, protože je narozdíl od id uživatelského účtu rozdílná i mezi více uživateli přihlášenými pod stejným uživatelským účtem. Zavedení kontroly zámku na session-id se tedy zajistí, že uživatelé přihlášení pod stejným uživatelským jménem a heslem nemohou ve stejný okamžik přistupovat do databáze a případně zde tímto způsobit konflikt v datech. Kontrola zámku a následné případné uzamknutí je prováděno atomicky v transakci z toho důvodu, že když nastane případ, že více uživatelů bude chtít uzamknout objekt ve stejný okamžik, objekt se uzamkne pouze pro jednoho uživatele a současně oba uživatelé dostanou korektní informaci o uzamknutí. Po kontrole zámku je provedena kontrola změněných či smazaných objektů a nastavení aktuálního času kontroly (viz předchozí podkapitola 5.6.2). Klientské straně se zašle informace o zamknutí objektu a o případných změnách v datech, které se pak zobrazí i v mapě. V tuto chvíli se již zpřístupní vlastní editace. Uživatel má možnost měnit geometrii objektu, jak tomu bylo popsáno v podkapitole 5.5.2, a dále popisné atributy ve formuláři. Tento formulář má stejné vlastnosti jako formulář vytvořený při zakládání nového objektu (viz předchozí podkapitola 5.6.2) a je naplněn podle nastavených atributů proměnné reprezentující daný objekt. Pokud uživatel klikne na tlačítko Zrušit”, ukončí se editace, objekt se znovu načte do mapy ” z globální javascriptové proměnné a zašle se PUT-Request na server. Na serveru se provede příkaz do databáze, který nastaví atribut locked na FALSE a smaže údaje v atributech locks id a locked time. Pokud však uživatel klikne na tlačítko Odeslat”, zkontroluje se validita geometrie i vyplněných ” hodnot ve formuláři a případě, že je vše v pořádku, zapíší se informace o objektu do formátu MyJSON”, který je popsán v předchozí podkapitole 5.6.2. Následně se celý text zašle serverové ” straně. Zde se opět kontroluje přihlášení uživatele z důvodu popsaného v předchozí podkapitole 5.6.2 a dále se kontroluje, zda je zámek na objektu přiřazen přihlášenému uživateli (kontroluje se session-id ). V případě, že ano, provede se UPDATE příslušných záznamů v tabulkách OBJECTS a VALUES v databázi a objektu se nastaví čas úpravy (time update). Zároveň


56

dojde k odstranění zámku na objektu (nastaví se atribut locked na FALSE a smažou se údaje v atributech locks id a locked time). Kontrola přiřazení zámku uživateli a následný případný UPDATE objektu v databázi jsou uzavřeny do transakce. V případě, že při provádění příkazů v databázi dojde k vyjímce, jsou změny vráceny zpět. Dále se znovu provádí kontrola aktualizace dat (viz výše) a v případě, že by došlo k nějaké změně od okamžiku počátku editace, zašle se tato změna klietovi. Na závěr celé akce dojde v případě, že UPDATE v databázi proběhl v pořádku, k přepsání dat v globální javascriptové proměnné aktuálními daty a případně k aktualizaci změněných dat v mapě. V opačném případě je uživatel upozorněn na neúspěšně provedený UPDATE dat chybovou hláškou. V příloze B.4 je uložen diagram popisující celou akci editace objektu.

5.6.4

Smazání objektu

Uživatel má dále možnost použít funkci Rušení prvků”, kterou může smazat objekt přiřazený ” k jeho účtu. Toto se opět kontroluje na základě hodnoty atributu editable”v proměnné kódu ” JavaScriptu. Pokud si uživatel ke smazání vybral svůj objekt, provádí se dále kontrola zámku a aktualizace dat (viz předchozí podkapitola 5.6.3). V případě, že objekt dosud nebyl uzamknut, dojde k jeho zamknutí (viz předchozí podkapitola 5.6.3). Následně jsou klientovi zaslány informace o zámku na objektu a případné provedené změny v datech jinými uživateli. Pokud objekt nebyl uzamčen a uživatel potvrdí, že chce skutečně ” objekt smazat”, je objekt nejprve smazán v mapě a následně je zaslán DELETE-Request na server. Zde se opět kontroluje, zda je uživatel přihlášen, zda je vlastníkem objektu a zda je zámek na objektu přiřazen danému uživateli. V případě, že všechny kontroly mají kladný výsledek, přistuje se do databáze, kde se provede smazání záznamu v tabulách OBJECTS a VALUES. Po smazání dojde k vložení záznamu do tabulky DELETED OBJ. Zde se ukládá id smazaného objektu, čas smazání (time del ) a users id (id uživatele, který objekt smazal). Toto se provádí z toho důvodu, aby u ostatních uživatelů v mapě byly po kontrole aktualizace dat též vymazány neexistující objekty. Kontrola zámku, smazání záznamu v tabulkách OBJECTS a VALUES a vložení záznamu do


57

tabulky DELETED OBJ je prováděno v transakci. V případě vzniku vyjímky při provádění těchto příkazů, dojde k navrácení změn v databázi. Dále se provádí výběr neaktuálních dat, které jsou na klientské straně následně zaktualizovány. V případě, že se uživatel rozhodne objekt nesmazat, zašle se na serverovou stranu PUT-Request, který provede odemknutí objektu. Když smazání dat v databázi úspěšně proběhne, má uživatel možnost pokračovat v odstraňování dalších objektů. V opačném případě je zobrazena chybová hláška a objekt je znovu načten do mapy z globální proměnné. V příloze B.5 je uložen diagram popisující akci smazání objektu.

5.7

Požadavky na hardware a software

V této podkapitole jsou popsány požadavky na hardware a software, který je zapotřebí k běhu aplikace.

5.7.1

Serverová strana

V této aplikaci je většina požadavků kladena na stranu serveru. Pro bezproblémový běh aplikace je třeba mít na počítači fungujícím jako server nainstalovaný webový server Apache, programovací jazyk PHP a databázi PostgreSQL s knihovnou PostGIS. Při vývoji aplikace byla použita následující konfigurace:

– operační systém Ubuntu 12.04.1 LTS, Windows 7 Professional Service Pack 1 – webový server Apache v. 2.2.22 – PHP v. 5.4.3 – databáze PostgreSQL v. 9.1.6 a PostgreSQL v. 9.1.3 s nainstalovanou knihovnou PostGIS v. 2.0.1

Na hardware nejsou kladeny žádné zvláštní požadavky. Je však dodržet požadavky určené výše uvedeným programovým vybavením.


5.7.2

58

Klientská strana

Vzhledem k tomu, že se jedná o webovou aplikaci, nejsou kladeny žádné vysoké požadavky na hardware ani software na klientské straně. Klient musí mít na svém PC nainstalovaný webový prohlížeč, ideálně Internet Explorer v. 9.0 nebo Mozillu Firefox v. 17.0.1 nebo Operu v. 12.11 či Chrome v. 23.0.1271.95, neboť na těchto prohlížečích byla aplikace testována a je zde plně funkční.

Kapitola 6. Testování

59

6 Testování

Aplikace byla v průběhu implementace i na závěr několikrát testována. Bylo prováděno ruční testování a tzv. jednotkové testování (Unit testing). Unit testing byl aplikován na část kódu aplikace běžící na serveru, tj. na kód v jazyce PHP. Přesněji řečeno, byly kompletně otestovány tyto třídy:

1. Authenticator - třída zajišťující přihlášení uživatele 2. Model - třída přistupující do databáze (obsahuje příkazy jazyka SQL) 3. ConvertObjects - třída se statickými metodami pro konverzi dat ve formátu GeoJSON do pole a zpět

Ostatní třídy serverové části aplikace (tj. třídy v adresáři /app/presenters/ ), soubory reprezentující vrstvu View (tj. soubory v adresáři /app/templates/ ) a kód klientské části aplikace byly důkladně otestovány manuálním způsobem.

6.1

Unit testing

Část kódu aplikace byla otestována tzv. Unit testingem. Jedná se o metodu, která testuje tzv. jednotky, čímž jsou v tomto případě myšleny jednotlivé metody třídy. Vlastní testy jsou reprezentovány opět metodami určité testovací třídy, které kontrolují, zda se testovaná funkce chová podle očekávání, tj. zda požadovaná akce byla danou testovanou funkcí správně provedena, případně se ověřuje, zda její návratová hodnota je v požadovaném tvaru v závislosti na parametrech funkce. K účelům Unit testingu byla použita knihovna PHPUnit v. 3.7.10 (informace a dokumentace jsou dostupné na stránkách [16]). Tato knihovna je určena pro testování kódu v jazyce


60

PHP. Knihovnu PHPUnit je nejprve třeba doinstalovat do PHP na server. Instalaci popisuje následující podkapitola (6.1.1). Testy lze pak spouštět přímo z příkazové řádky (příkazem phpunit (cesta_k_adresari_s_testy)) nebo s pomocí určitého vývojového prostředí (například NetBeans IDE - viz podkapitola 6.1.3).

6.1.1

Instalace PHPUnit

Před instalací knihovny PHPUnit je výhodné si nejprve stáhnout či zaktualizovat framework PEAR (PHP Extension and Application Repository), díky němuž je následná instalace a konfigurace PHPUnit snadná. PEAR lze stáhnout ze stránek [15] a nainstalovat následujícím příkazem v příkazové řádce: php go-pear.php Nyní je možné do PHP nainstalovat knihovnu PHPUnit pomocí následujících příkazů: pear channel-discover pear.phpunit.de pear channel-discover components.ez.no pear channel-discover pear.symfony-project.com pear install phpunit/PHPUnit Dále je možné doplnit knihovnu PHPUnit o nástroj Skeleton Generator, který umožňuje vygenerovat kostru”testovací třídy (připraví do souboru testovací třídy její definici spolu s prázd” nými testovacími metodami a metodami setUp() a tearDown(), které je třeba implementovat). Skeleton Generator je možné nainstalovat pomocí příkazu: pear install phpunit/PHPUnit\_SkeletonGenerator Vygenerování kostry”testovací třídy lze provést následovně: ” phpunit-skelgen --test -- (nazev_testovane_tridy) (cesta_k_souboru_testovane_ tridy) (testovaci_trida) (cesta_k_souboru_testovaci_tridy)

6.1.2

PHPUnit a Nette

Aby bylo možné otestovat metody využívající funkcionalitu Nette frameworku, bylo třeba získat a uložit do globální proměnné container aplikace. Systémový kontejner obsahuje všechny služby a parametry potřebné pro běh aplikace a je definován v zaváděcím souboru bootstrap.php. Pro testovací účely byl tento soubor nahrazen souborem testbootstrap.php, ve kterém byl container


61

uložen do globální proměnné. Dále bylo v tomto souboru, narozdíl od bootstrap.php, odstraněno spuštění vlastní aplikace. Pro testovací účely byla vytvořena nová prázdná databáze s tabulkami stejných názvů, jako mají tabulky testované aplikace. K této databázi byl nastaven přístup v konfiguračním souboru testconfig.neon. V souboru testbootstrap.php bylo následně nahrazeno načtení souboru config.neon definujícího přístup k ostré databázi načtením tohoto nového souboru. Testovací soubory spolu s konfiguračními soubory testbootstrap.php a testconfig.neon byly uloženy do adresáře app/tests v kořenovém adresáři aplikace.

6.1.3

PHPUnit a NetBeans

Ve vývojovém prostředí NetBeans IDE v. 7.2 byla psána celá aplikace a byly zde také spouštěny Unit testy. Prostředí NetBeans nabízí užitečné nástroje pro spouštění testů a vizualizaci jejich výsledků. Pro správnou funkčnost těchto nástrojů bylo nejprve třeba nastavit v konfiguraci NetBeans nástroje PHPUnit následující:

1. cestu ke spouštěcímu souboru knihovny PHPUnit (v adresáři serveru /php/phpunit.bat) 2. cestu k adresáři /tests v kořenovém adresáři aplikace 3. cestu k souboru testbootstrap.php v adresáři /tests

6.1.4

Vlastní testování

Metodou Unit testing s využitím knihovny PHPUnit byly otestovány metody třech tříd (Authenticator, Model a ConvertObjects). V každé testovací třídě (AuthenticatorTest, ModelTest a ConvertObjectsTest) byly definovány metody setUp() a tearDown(). Metoda setUp() se automaticky volá před spuštěním každé testovací metody. V této metodě byly nastaveny privátní proměnné a naplněna testovací databáze. V metodě tearDown(), která je volána automaticky po ukončení každé metody, je databáze vyprázdněna. Každá metoda třech testovaných tříd byla prověřena minimálně jednou testovací metodou tříd AuthenticatorTest, ModelTest a ConvertObjectsTest. K ověření správné funkčnosti a případnému výpisu chyb byly použity následující funkce:


62

– assertEquals() - porovnává zadanou testovanou hodnotu (např. návratovou hodnotu testované funkce) s předpokládanou hodnotou – assertNull() / assertNotNull() - ověřuje, zda je či není zadaná testovaná hodnota NULL – assertInstanceOf() - kontroluje, zda je testovaný objekt instancí zadané třídy – setExpectedException() - kontroluje, zda nastane očekávaná vyjímka – fail() - označí test jako chybný

6.2

Výsledky testování

Celkem bylo spuštěno 37 testovacích metod Unit testů, v nichž všechny testy skončily úspěchem. Obrázek vyhodnocení testů v programu NetBeans IDE je uveden v příloze E.1. Tímto byla tedy ověřena správná funkčnost metod tříd Authenticator, Model a ConvertObjects v serverové části aplikace. Funkčnost aplikace jako celku byla důkladně otestována manuálním způsobem přes uživatelské rozhraní. K tomuto byly použity nejnovější verze čtyř nejrozšířenějších webových prohlížečů, a to Internet Explorer v. 9.0.8112, Mozilla Firefox v. 17.0.1, Opera v. 12.11 a Chrome v. 23.0.1271.95. Na základě těchto testů byla aplikace shledána jako plně funkční a bez chyb. Ve všech výše zmíněných webových prohlížečích je vzhled aplikace stejný a stejným způsobem probíhají i veškeré operace klientské části aplikace. Pouze v Internet Exploreru je chod aplikace pomalejší než v ostatních prohlížečích. Uživateli se tedy doporučuje použít spíše prohlížeč Mozilla Firefox v. 17+ nebo Opera v. 12.11+ nebo Chrome v. 23+.

Kapitola 7. Zhodnocení

63

7 Zhodnocení

V rámci této diplomové práce byly zkoumány volně dostupné technologie určené k tvorbě webových aplikací a k práci s prostorovými daty a byly analyzovány možnosti jejich využití. Na základě toho byla vytvořena ukázková webová aplikace sloužící ke správě prostových dat. Správou prostorových dat se v tomto případě rozumí vytváření nových objektů, jejich editace a mazání přes webové rozhraní.

7.1

Technologie

Studované technologie byly popsány v kapitole 4. V zadání práce byl uveden PHP framework Nette, jehož použití se ukázalo jako užitečné a usnadňující implementaci aplikace. Výhodou tohoto frameworku je například využití architektury MVC, která zpřehledňuje kód a napomáhá jeho čitelnosti. Z funkcionalit nabízených frameworkem Nette byly využity zejména ty, které zajišťují spojení s databází a přístup k ní. Dále byl využit soubor funkcí obstarávající přihlašování a odhlašování uživatelů. Další doporučenou technologií v zadání byla knihovna PostGIS k databázi PostgreSQL. Tato knihovna umožňuje ukládání prostorových dat a nabízí funkce pro různé operace s těmito daty. Využití PostGIS se ukázalo jako vhodné pro uložení dat k této aplikaci. Z nabízených funkcí PostGIS byly použity pouze dvě, ST AsGeoJSON(), ST GeomFromText(), určené pro převod geometrie z nebo do textového formátu. Databáze MySQL v. 5+ též nabízí možnost uložení prostorových dat a poskytuje obdobnou funkcionalitu jako PostGIS, ale nemá implementovanou funkci pro převod geometrie do formátu GeoJSON, pouze do formátu WKT či WKB. Při implementaci byly dále použity javascriptové knihovny GeoExt, Ext JS a OpenLayers. V této aplikaci bylo nutné použít všechny tři knihovny, neboť každá z nich poskytuje určitou funkcionalitu, která je nezbytná pro chod aplikace. Spojení těchto tří knihoven pak nabízí


64

rozsáhlé možnosti při tvorbě webových mapových aplikací. Tato aplikace však vyžadovala určité rozšíření těchto funkcionalit, které bylo popsáno v podkapitole 5.3. V zadání byl dále doporučen Mapserver. Použití této open-source platformy určené pro publikování prostorových dat bylo nahrazeno využitím frameworku OpenLayers spolu s GeoExt a Ext JS. Data uložená v PostgreSQL databázi na serveru jsou zobrazována v mapě pomocí těchto javascriptových knihoven a není třeba je nijak převádět pro vizualizaci prostřednictvím Mapserveru. Byla však využita data z Mapserveru ČÚZK, konkrétně ortofoto, jako podkladová vrstva pro prostorová data této aplikace. Ortofoto je do mapového panelu na stránkách aplikace vloženo prostřednictvím WMS. V návrhu aplikace se naskytla otázka, jak řešit problém kontroly přístupu uživatelů k datům v databázi a problém zobrazení aktuálních dat na stránce ve webovém prohlížeči každého uživatele. Tyto problémy byly zanalyzovány a na základě toho bylo navrhnuto řešení (viz podkapitola 2.3 a 3.1). Řešení spočívalo v přiřazení každého objektu konkrétnímu uživateli, který se identifikuje při přihlášení do aplikace. Uživatel pak má přístup k editaci pouze těch objektů, které jsou přiřazeny k jeho účtu. Dále se zavedlo uzamykání objektů v okamžiku spuštění funkce editace či mazání v uživatelském rozhraní aplikace. K záznamu o objektu v databázi pak nemá žádný jiný uživatel přístup, než ten, který provedl uzamknutí. Tím se zajistilo, že ani uživatelé přihlášení pod stejnými uživatelskými údaji nemohou zároveň editovat ten samý objekt. Aktuálnost dat zobrazených na stránce není zajištěna stoprocentně. Uživatelé nemají zobrazena aktuální data v každý okamžik, jak by tomu bylo v ideálním případě. Na základě analýzy provedené v podkapitole 3.1 však bylo navrženo optimální řešení, díky němuž se data aktualizují před započtením provádění změn v datech, tedy v okamžiku, kdy uživatel nejvíce potřebuje znát stav dat v databázi. Výše popsané řešení lze nahradit zavedením technologie Web Socket (popsané v podkapitole 2.3.3.2). Tato technologie by zejména lépe zajistila zobrazení aktuálních dat na stránkách uživatelů, neboť by se data u klienta obnovovala hned po provedené změně v databázi. Technologie Web Socket byla v této práci zanalyzována a její zavedení je jedním z návrhů na zdokonalení stávající aplikace.


7.2

65

Struktura databáze

Dalším specifickým problémem řešeným v této práci byl návrh a vytvoření takové struktury databáze, která by podporovala uložení co největšího množství vektorových dat s definovanými popisnými vlastnostmi. Použití takovéto struktury databáze je v tomto případě výhodné, neboť není předem specifikáno, s jakými daty bude aplikace pracovat. V případě, že by to však bylo specifikováno, bylo by naopak výhodnější použít klasickou strukturu databáze navrženou přesně na míru dané situace. Nevýhody zde použité struktury databáze totiž spočívají ve složitosti SQL dotazů a v řídkosti”tabulky s hodnotami popisných vlastností. ”

7.3

Funkčnost aplikace

Aplikace byla otestována pomocí Unit testů a manuálního testování (viz kapitola 6). Na základě výsledků obou způsobů testování se dospělo k závěrů, že aplikace je plně funkční a je podporována nejnovějšími verzemi nejrozšířenějších webových prohlížečů.

7.4

Návrhy na rozšíření aplikace

Na základě obecných požadavků na aplikaci a provedené analýzy byly navrženy konkrétní funkční požadavky, které definovaly funkce přístupné uživatelům přes rozhraní aplikace (viz kapitola 3.4). Dle těchto konkrétních požadavků byla aplikace naimplementována. Výsledná aplikace plně splňuje všechny navržené požadavky. Nabízí se však různá rozšíření stávající aplikace. Jeden z možných směrů rozšíření se týká vytvoření pokročilejších funkcí pro operace s geoprostorovými objekty v mapě. Takovýchto funkcí lze navrhnout a vytvořit nekonečné množství. Příkladem může být zavedení více typů editace objektů v mapě. Ve stávající aplikaci je možné upravit geometrii pouze změnou polohy lomových bodů objektu, vložením nového lomového bodu nebo smazáním lomového bodu. U bodových objektů lze pouze přemístit bod na jinou pozici. Uživatel by však mohl mít na výběr kromě tohoto druhu editace také z prostého posunu či otočení objektu. Stávající verze aplikace umožňuje definovat souřadnice lomových bodů objektu při jeho vytváření a to zadáním hodnot X a Y do formuláře. Návrhem na rozšíření možností aplikace by mohlo být


66

i doplnění této fukcionality k editaci geometrie objektů. Tedy kromě možnosti změny polohy lomového bodu objektu grafickým způsobem v mapě by se mohla přidat možnost určit jeho novou polohu zadáním hodnot souřadnic. Dále by mohlo být užitečné zavedení snappingu na ten samý objekt. V současné verzi aplikace je možné využít dochytávání lomových bodů objektu pouze na body ostatních objektů. V některých případech se však uživateli může hodit snapnout”lomový bod objektu na jiný bod ” toho samého objektu. Například při modifikaci geometrie by mohl uživatel chtít přesunout bod po hraně objektu (tedy snapnout”se na hranu toho samého objektu). ” Knihovny OpenLayers i PostGIS podporují různé typy geometrie objektů, například i složitější struktury složené z elementárních geometrií, jako MultiPoint, MultiLineString, MultiPolygon a Collection. Vytvoření objektů s takovouto geometrií však současná aplikace neumožňuje. Zavedení této funkcionality je také námětem na další rozšíření aplikace. Dále lze doplnit možnosti aplikace i zcela odlišnými funkcemi. V této práci jsem se například nevěnovala správě uživatelských účtů prostřednictvím uživatelského rozhraní. Uživatelé v současné době nemají možnost založit si účet přes stránky aplikace a případně tento účet spravovat, například měnit osobní údaje či heslo. Toto by jistě bylo vhodné doplnit. Jak bylo uvedeno výše, v této práci byla navržena specifická struktura databáze vhodná pro ukládání mnoha typů dat. Tato vlastnost aplikace však není plně využita, neboť v současné době není možné přes webové rozhraní přidávat do databáze další typy dat a jejich vlastnosti. Tato činnost by připadla roli Administrator, která zatím není vůbec zavedena. Vytvoření rozhraní pro roli Administrator je dalším návrhem na rozšíření stávající aplikace. S tímto souvisí doplnění funkcí pro správu všech prostorových objektů uložených v databázi, definování nových typů objektů a jejich vlastností, správu uživatelských účtů všech uživatelů aplikace a dalších funkcionalit. V podkapitole 7.1 byl nastíněn i návrh na zavedení technologie Web Socket do této aplikace v rámci jejího dalšího zdokonalování.

Kapitola 8. Závěr

67

8 Závěr

Cílem této diplomové práce bylo se seznámit s volně dostupnými technologiemi určenými k tvorbě webových aplikací a k práci s prostorovými daty, ověřit jejich možnosti a omezení a na základě toho vytvořit ukázkovou webovou mapovou aplikaci. Před započetím implementace ukázkové aplikace byla nejprve provedena analýza (viz kapitola 2) a návrh (viz kapitola 3) dané aplikace. Po navržení byla aplikace implementována. Konkrétní způsob implementace a řešení problémů uvedených v analýze jsou popsány v kapitole 5. Dále byla aplikace prověřena testy (viz kapitola 6) a na závěr byla v kapitole 7 zhodnocena z hlediska použitých technologií, řešení problémů spojených se správou prostorových dat a celkové funkčnosti aplikace. Použití frameworku Nette, databáze PostgreSQL, knihoven PostGIS, GeoExt, Ext JS a OpenLayers při implementaci aplikace se ukázalo jako velmi vhodné a spojení těchto technologií je doporučováno využít i pro tvorbu jiných webových mapových aplikací. Mapové aplikace mohou uživatelům nabízet různé funkce pro práci s prostorovými daty, jejichž implementace často vyžaduje rozšíření funkcionalit poskytovaných použitými technologiemi. Pro tuto aplikaci bylo nutné rozšířit funkcionalitu OpenLayers. Technologie Mapserver v aplikaci využita není. Její použití je vzhledem k využití ostatních technologií nadbytečné. Stávající aplikaci je vhodné vylepšit zavedením technologie Web Socket, která by například zajistila téměř okamžité zobrazení aktuálních dat na stránkách všech uživatelů. Použití této technologie bylo nahrazeno aplikací vlastního navrženého systému pro zajištění zobrazení aktuálních dat. Dále byl navržen a aplikován systém pro řízení přístupu uživatelů k datům v databázi prostřednictvím webového rozhraní. Pro zajištění podpory správy co nejvíce typů vektorových dat byla navržena specifická struktura databáze. Funkčnost aplikace byla otestována manuálně i pomocí Unit testů a byla shledána jako korektní

Kapitola 8. Závěr

68

a plně funkční. V průběhu implementace byla aktuální verze aplikace dostupná na adrese http://inggeo. fsv.cvut.cz:6080/dev/petras/diplomka/www/. Kód výsledné aplikace je v podobě projektu NetBeans IDE umístěný na CD přiloženém k této práci. Dále je na tomto CD umístěna dokumentace ke kódu klientské i serverové části aplikace, dávkový soubor pro naplnění databáze, zdrojové kódy Unit testů, text této diplomové práce, zdrojové kódy textu v jazyce LATEX, instalační příručka s návodem ke zprovoznění aplikace na serveru a uživatelská příručka.

Kapitola 9. Literatura

69

9 Literatura

[1] AJAX Tutorial. [online]. [cit. 27.11. 2012]. Dostupné z WWW: http://www.w3schools. com/ajax/default.asp. [2] ArcGIS. [online]. [cit. 20.11. 2012]. Dostupné z WWW: http://www.esri.com/software/ arcgis. [3] Bizagi Process Modeler. [online]. [cit. 22.11. 2012]. Dostupné z WWW: http://www. bizagi.com/index.php?option=com_content&view=article&id=95&Itemid=107. [4] Enterprise Architect.

[online]. [cit. 22.11. 2012]. Dostupné z WWW: http://www.

sparxsystems.com.au/. [5] Firebug. Web Development Evolved. [online]. [cit. 8.12. 2012]. Dostupné z WWW: https: //getfirebug.com/. [6] GeoExt 2 - Status Page. [online]. [cit. 18.11. 2012]. Dostupné z WWW: http://geoext. github.com/geoext2/. [7] The GeoJSON Format Specification. [online]. [cit. 27.11. 2012]. Dostupné z WWW: http: //www.geojson.org/geojson-spec.html. [8] Json Parser Online. [online]. [cit. 27.11. 2012]. Dostupné z WWW: http://json.parser. online.fr/. [9] MISYS.

[online]. [cit. 20.11. 2012]. Dostupné z WWW: http://www.gepro.cz/

geograficke-informacni-systemy/misys-a-misys-web/misys/. [10] NetBeans IDE. The Smarter and Faster Way to Code. [online]. [cit. 7.12. 2012]. Dostupné z WWW: http://netbeans.org/. [11] Node.js. [online]. [cit. 8.12. 2012]. Dostupné z WWW: http://nodejs.org/.

Kapitola 9. Literatura [12] OGC. About OGC.

70 [online]. [cit. 17.11. 2012]. Dostupné z WWW: http://www.

opengeospatial.org/ogc. [13] OpenLayers. [online]. [cit. 18.11. 2012]. Dostupné z WWW: http://dev.openlayers. org/docs/files/OpenLayers-js.html. [14] OpenLayers: Free Maps for the Web. [online]. [cit. 18.11. 2012]. Dostupné z WWW: http: //openlayers.org/. [15] PEAR - PHP Extension and Application Repository. [online]. [cit. 6.12. 2012]. Dostupné z WWW: http://pear.php.net. [16] PHPUnit Manual. [online]. [cit. 6.12. 2012]. Dostupné z WWW: http://www.phpunit. de/manual/current/en/index.html. [17] PostGIS. About PostGIS. [online]. [cit. 17.11. 2012]. Dostupné z WWW: http://opengeo. org/technology/postgis/. [18] PostGIS. What is PostGIS?

[online]. [cit. 17.11. 2012]. Dostupné z WWW: http:

//postgis.refractions.net/. [19] Quantum GIS. [online]. [cit. 20.11. 2012]. Dostupné z WWW: http://www.qgis.org/. [20] Sencha Ext JS. JavaScript Framework for Rich Apps in Every Browser. [online]. [cit. 18.11. 2012]. Dostupné z WWW: http://www.sencha.com/products/extjs. [21] Stavové [cit.

kódy 27.11.

a

hlášení

2012].

v

Dostupné

odpovědi z

protokolu

WWW:

HTTP.

[online].

http://interval.cz/clanky/

stavove-kody-a-hlaseni-v-odpovedi-protokolu-http/. [22] W3C. XMLHttpRequest Level 2. [online]. [cit. 27.11. 2012]. Dostupné z WWW: http: //www.w3.org/TR/XMLHttpRequest/. [23] Web Sockets. [online]. [cit. 30.11. 2012]. Dostupné z WWW: http://www.zdrojak.cz/ clanky/web-sockets/. [24] Welcome to MapServer.

[online]. [cit. 20.11. 2012]. Dostupné z WWW: http://

mapserver.org/. [25] What’s AJAX? [online]. [cit. 27.11. 2012]. Dostupné z WWW: https://developer. mozilla.org/en-US/docs/AJAX/Getting_Started.

[26] YUI Compressor. [online]. [cit. 20.11. 2012]. Dostupné z WWW: http://developer. yahoo.com/yui/compressor/. [27] Úvod do JSON. [online]. [cit. 27.11. 2012]. Dostupné z WWW: http://www.json.org/ json-cz.html. [28] Asleson, Ryan a Schutta, N. T. AJAX. Vytváříme vysoce interaktivní webové aplikace. Computer Press, a.s., 2006. překlad Zemánek, J. 269 s., ISBN 80-251-1285-3. [29] Dvořák, M. Návrh webových služeb dle REST architektury: bakalářská práce. Praha: ČVUT Fakulta elektrotechnická, 2012. 45 s. [online]. [cit. 26.11. 2012]. Dostupné z WWW: https://dip.felk.cvut.cz/browse/pdfcache/dvoram28_2012bach.pdf. [30] Landa, M. Geoprostorové databáze, PostGIS. [online]. Praha: ČVUT Fakulta stavební, Katedra mapování a kartografie, 2010. [cit. 17.11. 2012]. Dostupné z WWW: http:// josef.fsv.cvut.cz/~gin/yfsg/Free-Software-GIS-07-postgis.pdf. [31] Malý, M. REST: architektura pro webové API. 2009. [online]. [cit. 26.11. 2012]. Dostupné z WWW: http://www.zdrojak.cz/clanky/rest-architektura-pro-webove-api/. [32] Obe, Regina O. a Hsu, L. S. PostGIS in Action. Manning Publications Co., 2011. 492 s., ISBN 9781935182269. [33] Powers, S. Learning JavaScript, 2. ed. O´Reilly Media, 2009. 269 s., ISBN 978-0-59652187-5.

Prˇı´lohy

Příloha A. Seznam digitálních příloh

I

A Seznam digitálních příloh

Přiložené CD obsahuje:

/ – Dokumentace zdrojových kódů aplikace

doc/ doc js/

– Dokumentace ke kódu klientské části aplikace

doc php/

– Dokumentace ke kódu serverové části aplikace

install/

– Adresář se soubory ke zprovoznění aplikace na serveru

davka.sql

– Dávkový soubor pro naplnění databáze

php.ini

– Ukázkový konfigurační soubor pro nastavení webového serveru – Zdrojové kódy aplikace

src/ app/

– Zdrojové kódy serverové části aplikace

libs/

– Framework Nette

log/

– Adresář pro zapisování chyb na serveru

nbproject/

– Projekt NetBeans IDE

temp/

– Adresář pro zapisování dočasných souborů

tests/

– Zdrojové kódy Unit testů

www/

– Veřejný adresář

css/

– Zdrojové kódy s kaskádovými styly

images/

– Adresář s obrázky webové stránky aplikace

js/

– Kód v jazyce JavaScript

client/ build/ části aplikace

– Adresář se zdrojovými kódy klientské části aplikace a knihovnami – Spojený a minimalizovaný soubor se zdrojovými kódy klientské

compressor/ – Program pro vytvoření minimalizovaného souboru lib/

– Kódy knihoven OpenLayers, GeoExt a Ext JS

src/

– Zdrojové kódy klientské části aplikace

build.xml

– Konfigurační soubor pro spojení a minimalizaci zdrojových kódů

text/

– Text této diplomové práce

src/

– Zdrojové kódy textu v jazyce LATEX

DP svobodova.pdf/

– Tato diplomová práce ve formátu PDF

II

Příloha B. Diagramy BPMN (Business Process Model and Notation)

B Diagramy BPMN (Business Process Model and Notation)

Obrázek B.1: Diagram akce přihlášení uživatele

III

Obrázek B.2: Diagram akce načtení stránky

IV

Obrázek B.3: Diagram akce vytvoření nového objektu

V

Obrázek B.4: Diagram akce změna objektu

VI

Obrázek B.5: Diagram smazání objektu

VII

Příloha C. Ukázky kódu

C Ukázky kódu

Obrázek C.1: Jednoduchý příklad použití funkcí jako tříd v JS.

Obrázek C.2: Jednoduchý příklad polymorfismu v jazyce JS.

VIII

Obrázek C.3: Příklad dědičnosti v jazyce JS.

Obrázek C.4: Ukázka zápisu dat ve formátu JSON.

IX

Obrázek C.5: Ukázka zápisu dat ve formátu GeoJSON.

X

Obrázek C.6: PUT-Request

Obrázek C.7: Odchytávání”Requestu na serveru ”

XI

Příloha D. Ukázky aplikace

D Ukázky aplikace

Obrázek D.1: Ukázka webové aplikace

XII

Obrázek D.2: Ukázka webové aplikace se spuštěnou funkcí Info

Obrázek D.3: Ukázka webové aplikace se spuštěnou funkcí Měření plochy

XIII

Obrázek D.4: Ukázka aplikace se spuštěnou funkcí Kreslení prvků - grafické definování geometrie

Obrázek D.5: Ukázka aplikace se spuštěnou funkcí Kreslení prvků - zadání číselných hodnot souřadnic XIV

Obrázek D.6: Ukázka webové aplikace se spuštěnou funkcí Kreslení prvků - vyplnění popisných vlastností objektu

Obrázek D.7: Ukázka webové aplikace se spuštěnou funkcí Editace prvků XV

Obrázek D.8: Ukázka webové aplikace se spuštěnou funkcí Rušení prvků

XVI

Příloha E. Unit testing

XVII

E Unit testing

Obrázek E.1: Výsledek Unit testů

Správa prostorových dat v prostředí webu

Recommend Documents