MASARYK UNIVERSITY Faculty of Science Department of Geography
Zdeněk HYNEK
APPLICATION OF WEB TECHNOLOGIES FOR DATA MAINTENANCE WHILE USING
WEB INTERFACE
Diploma Thesis
Thesis Advisor: RNDR. Tomáš Řezník, Ph.D.
Brno 2011 Author's first and last name: Zdeněk Hynek
Diploma thesis name: Application of Web technologies for data
maintenance while using Web interface
Field of study: Geographical Cartography and Geoinformatics
Thesis Advisor: RNDr. Tomáš Řezník, Ph.D.
Graduation year : 2011
Anotace
Diplomová práce představuje webovou aplikaci pro on-line editaci prostorových dat. V teoretické části podává práce základní přehled použitých technologií, relevantních mezinárodních standardů a teoretických konceptů na jejichž základě byla aplikace vyvinuta. Aplikace byla testována v rámci terénního experimentu v listopadu 2008 v rámci výzkumného záměru Dynamická vizualizace v krizovém managementu řešeného v rámci Laboratoře geoinformatiky a kartografie. Na základě výsledku experimentu je aplikace stručně zhodnocena a jsou načrtnuty možnosti dalšího vývoje.
Annotation
The thesis deals with development of an exemplary web application for on-line editing of geo-spatial data. The written part presents overview of technologies used, international standards involved and theoretical concepts which laid foundation for the development of application. The application has been tested during the field experiment testing in November 2008 as part of the Dynamic Geovisualization in the Crisis management research project at Laboratory on Geoinformatics and Cartography. Based on the experiment results, the brief evaluation of application's functionality and usability is made, together with prospects for further development.
Klíčová slova: Webové služby, WMS, WFS, OGC, Krizový management
Keywords: Web services, WMS, WFS, OGC, Crisis Management
I hereby affirm that I have written the thesis by myself under the guidance of RNDr. Tomáš Řezník, Ph.D. and I have listed all the literature used in the list of references.
In Hradec Králové, 11th January 2011 ______signature of the author Acknowledgement
I would like to thank Tomáš Řezník for all the patience, guidance and help with the thesis writing and also for the unconditional support of all the ideas, even the bad ones, throughout years of my studies. I would also like to thank Martin Pulicar for always pushing me a wee bit closer to impossible. Lastly, I would like to thank Geogrmelec, and everybody who made it possible, for not stopping making sense when everything else was a mess. Also, my family. Table of Contents 1. GEOGRAPHIC DATA PUBLISHING ON WEB...... 10 1.1 Representation of geographical data...... 10 1.1.1 Discrete object view...... 10 1.1.2 Continuous field view...... 11 1.2 Representation of geographical data in digital form...... 11 1.3 Representation of geographical data on web...... 12 1.3.1 Raster formats ...... 12 1.3.2 Vector formats...... 13 1.4 Geography Markup Language...... 14 1.4.1. GML General scheme...... 15 1.4.2. GML Profiles...... 15 1.4.3 GML Application schemes...... 16 1.4.4.1 Difference between GML 2 and GML 3.2.1...... 16 1.4.4.2 CityGML...... 16 1.4.4.3 SWE...... 17 1.5 Publishing maps on the Internet...... 18 1.5.1 Static maps publishing...... 19 1.5.2 Interactive map publishing...... 20 1.5.2.1 Client-side extensions...... 20 1.5.2.2 Server-side extensions...... 21 1.5.2.3 Mixed solutions...... 21 1.6 Distribution of geographic data...... 22 1.6.1 Web services overview...... 23 2. CARTOGRAPHIC VISUALIZATION ON WEB...... 24 2.1 Web Map Service...... 24 2.1.1. Principles of WMS...... 24 2.1.2. Mechanics behind WMS...... 25 2.1.3 GetCapabilities, GetMap and GetFeatureInfo services...... 25 2.1.4. WMS servers...... 28 2.1.5. Geospatial Web...... 28 2.2 Symbology encoding language and symbology layer descriptor...... 29 2.2.1. Symbology Encoding language...... 29 2.2.2. Styled Layer Descriptor...... 30 2.4 GML vs. SLD...... 31 2.4.1 Keyhole Markup Language...... 32 2.5 Filtering encoding...... 34 2.5.1. Operators...... 34 3 PRINCIPLES OF WEB SERVICES...... 35 3.1 Web Services Architecture...... 35 3.1.1 Architecture overview...... 35 3.1.2 Components...... 36 3.1.2.1 Universal Description Discovery and Integration...... 36 3.1.2.2 Simple Object Access Protocol...... 37 3.1.2.3 Web Services Description Language...... 39 3.1.3 Types of web service...... 40 3.1.3.1 Use case...... 40 3.1.3.2 Sensors...... 43 3.2 Web Feature Service...... 43 3.2.1 Principles...... 43 3.2.2 Mechanics...... 44 3.2.3 GetCapabilities, DescribeFeatureType, GetFeature, GetGmlObject LockFeature...... 45 3.2.4 Transaction...... 47 3.3 Standardization of web services...... 49 3.3.1 Why standardization...... 49 3.3.2 Web services standardization...... 50 4. USAGE OF WEB MAPS AND SERVICES ON WEB...... 51 4.1 Functional requirements...... 51 4.1.1 Visualization...... 51 4.1.2 Editing...... 52 4.1.3 Authoring...... 53 4.1.4 Printing...... 53 4.2 Non-functional requirements...... 53 4.2.1 Performance...... 53 4.2.2 Usability...... 54 4.2.3 Extensibility...... 54 4.2.4 Interoperability...... 54 4.2.5 Resilience...... 55 5. APPLICATION FOR ON-LINE GEOSPATIAL DATA MANAGEMENT...... 56 5.1 Research project...... 56 5.1.1 Project description ...... 56 5.1.2 Required functionality...... 57 5.2 Architecture...... 57 5.2.1 Sensors and GPS subsystem...... 58 5.2.2 Mapping and database subsystem...... 58 5.2.3 Mapping clients subsystem...... 59 5.2.3.1 Mapping client...... 59 5.2.3.2 Editing client ...... 59 5.3 Implementation and challenges...... 61 5.3.1 Implementation...... 61 5.3.1.1 Used technologies and frameworks...... 62 5.3.1.2 Application mechanics...... 63 5.3.1.3 Class structure, coding style...... 66 5.3.1.4 User interface design...... 67 5.3.2 Challenges...... 68 5.3.2.1 Cross-browser compatibility...... 69 5.3.2.2 Transformation inaccuracies ...... 70 5.3.2.3 Complex symbology...... 71 6.CONCLUSION...... 72 6.1. Management summary...... 72 6.2 Further development...... 73 Abbreviations list...... 74 REFERENCES...... 76 ATTACHMENTS...... 82 At the beginning, there was a cable. The cable laid on the sea floor to carry communication between countries. The cable that was the earliest forerunner of the World
Wide Web. The cable which took us places sci-fi writers from the fifties could never imagine.
1. GEOGRAPHIC DATA PUBLISHING ON WEB
1.1 Representation of geographical data
The world is an infinitely complex system. This poses a fundamental problem for geography, which strives to describe it. How can something infinite be described with finite methods of science?
To strip down some of the complexity, researches resort to the usage of models. These models allow a significant simplification of the world by retaining essential objects and relationships and discarding needless. From many models of representing geographic data, the discrete object view and continuous field view models, gained much attention and will be discussed further. They are called views because they provide the fundamental schemes how to look at the world. (Longley et al., 2005)
1.1.1 Discrete object view
In the discrete object view, the world is empty container that is littered with well- defined discrete objects. The distribution of human population, for instance, can be imagined as a space filled with settlements and cities. The discrete objects are separable and countable, meaning they can be easily distinguished from each other. This model fits tightly for
10 describing biological organism, man-made objects and so on. (Longley et al., 2005)
1.1.2 Continuous field view
The continuous field view uses sets of variables, each measurable at any point on the
Earth's surface, to describe the geographic world. Value of variables changes smoothly across the surface. Natural phenomena, such as elevation and air temperature, and some phenomenas of human geography, such as density of population, are well represented with this view. (Longley et al., 2005)
1.2 Representation of geographical data in digital form
The two models described above provide theoretical foundation for the two major data models used for computer representation, grid and vector. In practice, the grid data model is almost always used for continuous field view and vector data model for discrete object view. (Longley et al., 2005)
Grid data model divides space into an array of rectangular cells. To each cell, value of geographic phenomena in question is assigned. (Longley et al., 2005)
Vector data model stores geographical data as mathematical formulae. Thus, vector data, unlike grid data, are scalable. (Longley et al., 2005)
11 Figure 1: The same surface represented in vector and raster, source: [http://www.arts- humanities.net/system/files/images/vector_raster.preview.png]
1.3 Representation of geographical data on web
1.3.1 Raster formats
Grid data are stored in a raster graphics image, also called bitmap. Among many different formats for storing grid data, the three of them, Graphics Interchange Format
(GIF), Joint Photographics Experts Group (JPEG) and Portable Network Graphic (PNG), have gained an immense dominance over the others in displaying graphics content on the web. (Chastain, 2010)
GIF format is 8-bit graphics, meaning it can accommodate only 256 colors. This signals it is mostly used only for simple graphics, namely icons. JPEG, on the other hand is widely used whenever image quality and color fidelity is of utmost importance, e.g. for color photography. PNG is official recommendation of the World Wide Web Consortium (W3C) for bitmap graphics on Web and it offers many advance features GIF lacks, namely support for 32-bit graphics. (Web style guide, 2008)
12 1.3.2 Vector formats
With vector data, unfortunately, developers cannot choose format which would render data without issues across different browsers. The major vector formats used on the web, Scalable Vector Graphics (SVG) and Vector Markup Language (VML) lack universal cross-browser support, forcing numerous developers to use non-standard technologies, namely Flash or Silverlight. (Lrbabe, 2009)
SVG is a vector format promoted as an official standard for vector graphics on web by
W3C. Although, it has gained substantial popularity among web developers over the years, the lack of support in the most widely used web browser, Internet Explorer, prevent the technology to become universal solution for vector graphic on web. This might change with announced SVG support in the latest version Microsoft's browser Internet Explorer 9. (IEBlog,
2010)
Vector Markup Language has been created by the Microsoft corporation and proposed as standard for vector graphics on the web to the W3C in 1998. The W3C favoured
SVG and the development of VML to be ceased. Internet Explorer is the only browser with native support of VML. (W3C, 1998)
Numerous projects have been developed to solve SVG/VML dilemma and provide web developers with cross-browser support. Many of them take form of JavaScript libraries, such as Dojo, Raphael or most recently Google's SVG Web. (W3C, 2010a), (W3C, 2010b), (The
Register, 2010)
Flash platform is the most widely used technology when it comes to displaying vector in web browser. The visualization in this case is not done by web browser, but by the
Adobe Flash player plug-in. In comparison with SVG and VML, Flash offers wide
13 penetration. (Adobe, 2010) However, it represents proprietary format and does not promote the usage of latest open standard technologies (HTML5, CSS3) which are likely to shape future of the web. (Jobs, 2010)
1.4 Geography Markup Language
The formats described above provide means of representing geographical objects as any other graphic on web. However, geographers research individual objects and their relations in space, and for that, these formats are of little use. That is why Open Geospatial
Consortium (OGC), came up with Geography Markup Language (GML), an XML-based language, which describes geographical features in an abstract form and is used by geographical systems to store objects in as interchange format allowing for sharing geographical data over networks. (Open Geospatial Consortium, 2007a)
As GML relates closely to topic of the thesis, it is described into greater depth than previous formats.
14 1.4.1. GML General scheme
As well as others XML-based language, GML has a general scheme, which define sets of elements, sometimes called primitives, defining objects which can be used to describe geographical datasets. Some of them describe real-world geographical objects (feature), some describe spatial relationships (topology) and some carry metadata information (time, unit of measure) or visualization attributes (map presentation styling rules). The general scheme can be used to depict spatial datasets containing points, lines and polygons. (Open
Geospatial Consortium, 2007a)
1.4.2. GML Profiles
Full adoption of GML standard requires a lot of work so developers might opt for adopting only subsets of GML specification called profiles. The aim of profiles is to simplify complexity of the full standard and promote more rapid adoption of GML as standard for spatial data. (Open Geospatial Consortium, 2007a)
One of the simplest profiles is the Point Profile aiming to application which deals only with one dimensional spatial data of type of point and have no need of other complex
GML datatypes. The most widely adopted profile is Simple Feature Profile. Besides points, it allows for the usage of more dimensional data types such as lines and polygons, as well as their aggregations, such as multilines and multipolygons. As such, it allows to describe geometrically complex datasets. However, this profile does not allow to nest features deeper than one level and discards the support for more complex and abstract datatypes as coverage or topology primitives. (Open Geospatial Consortium, 2007a),(Open Geospatial Consortium, 2007b)
15 1.4.3 GML Application schemes
Aside from the GML general scheme, which defines the most general abstract elements, communities of developers are allowed to specify their own schemes, called application schemes. As these application schemes are created with specific purpose on mind, they can define much more concrete elements which get closer to real life objects.
Among many others, CityGML for describing 3d city models, TigerGML for storing United
States census data and Aeronautical Information Exchange Model (AIXM) for exchanging civil aviation data have been widely adopted. (Open Geospatial Consortium, 2007a),(Open
Geospatial Consortium, 2007b)
1.4.4.1 Difference between GML 2 and GML 3.2.1
Up to version 2, GML could hold only 2D linear geometries. Its geometry model was based on Simple Features Geometry and it was unable to store complex geometries, defined by the technical committe ISO/TC 211. Therefore, it was decided the new version of GML was necessary. (Open Geospatial Consortium, 2001)
Starting with version 3.0, GML geometry model is based on the norm ISO 19107, meaning it encompasses a far greater number of geometry classes than it predecessors with either 0D, 1D, 2D or even 3D geometries, such as composite curves, surface and curve primitives and else. (Burggraf, 2005)
1.4.4.2 CityGML
CityGML, an application scheme for GML, is “an open data model and XML-based format for the storage and exchange of virtual 3D city models.” (Open Geospatial Consortium,
16 2007c) It has been specified to allow the re-usage of expensively collected data for creating 3d models in different application fields and it defines basic entities, attributes and relations of city models. (Open Geospatial Consortium, 2007c)
Objects can be described with basic geometrical and topological properties as well as more complex thematic attributes. Same object can be defined with varying complexity for five different levels of detail. (Open Geospatial Consortium, 2007c)
1.4.4.3 SWE
Sensor Web Enablement (SWE) is an OGC initiative which aims to build a framework for connecting web-accessible sensors and sensor systems, such as air pollution monitors, webcams, satellite imagery and else. This framework would allow for leveraging huge amount of data collected by sensors every day in many application fields spanning from environmental monitoring to facilities management. (Open Geospatial Consortium, 2007d)
SWE focuses on development of set of standards to “enable the discovery, exchange, and processing of sensor observations, as well as the tasking of sensor systems.” (Open
Geospatial Consortium, 2007d) These standards should allow user or application to discover suitable sensor systems, explore its capabilities, access its parameters, retrieve real-time data, task a sensor to acquire specific observation and subscribe to alerts sensor might issue whenever certain criteria are met. The following specifications has been prototyped:
–Observations & Measurements Schema (O&M)
–Sensor Model Language (SensorML)
–Transducer Markup Language (TransducerML or TML)
17 –Sensor Observations Service (SOS)
–Sensor Planning Service (SPS)
–Sensor Alert Service (SAS)
– Web Notification Services (WNS) (Open Geospatial Consortium, 2007d)
On 25 April 2010, the OGC has closed public comment period for the proposed OGC
SWE Service Model 2.0 Standard document. This document, once accepted as a new standard, will introduce significant modification to SOS and SPS. (Open Geospatial
Consortium, 2010b)
Figure 2: Overview of sensors application within SWE, source: [http://www.opengeospatial.org/ogc/markets-technologies/swe]
1.5 Publishing maps on the Internet
Different techniques of usage of this formats have been developed to deliver geographic data to users over the Internet. There are two types of web-based maps, which
18 differ in manner they can be interacted with, static or interactive.
1.5.1 Static maps publishing
The static map publishing uses raster images embedded into an HTML page and just that. Using imagemaps, different image areas have associated different hot links which lead related informations, similarly to traditional hyperlinks. More advanced techniques take advantage of web forms and Common Gateway Interface (CGI), where client specifies in which layers or areas it is interested in and use a web form to send request to server. The server uses CGI to delegate the request to specialize software, such as mapping server which produces map image, handles response and pass it to client. (Peng, 2003) While some authors
(Peng, 2003) consider CGI to be a method of static map publishing, some others authors
(Brown and Kraak, 2001) acknowledge its capabilities by classifying it as method of interactive map publishing.
These techniques have only minimum requirements for clients machine as all the responsibilities lay on server. However, each new request generates response that needs to be processed regardless what might have been present on the client side, thus generating huge amount of network traffic and slowing down the process. (Peng, 2003)
19 Figure 3: Static map publishing architecture scheme, source: (Brown and Kraak, 2001)
1.5.2 Interactive map publishing
Interactive mapping applications try to solve issues of static map publishing by introducing either client or server-side extensions.
1.5.2.1 Client-side extensions
To provide users with richer user experience and interactivity within a browser, either scripting languages or plug-ins are used. In the first case, script, more often than not written in JavaScript, access HTML elements on page and modifies them in response to user actions. In the second case, the visualization of map and user interaction is handled by plug- in (or applet), small piece of software loaded into the browser. Although plug-ins can offer very rich functionality, they can also introduce serious accessibility issues for users on machines without the plug-ins installed and without the rights for installation. Most advanced client-side solution, outside the scope of web browser, presents concept of thick
20 client which takes form of a desktop GIS software capable of visualizing data obtained across the network. (Peng, 2003)
Figure 4: Interactive map publishing architecture scheme with client-side extension, source: (Brown and Kraak, 2001)
1.5.2.2 Server-side extensions
The server extension takes an idea of CGI and push it one step further. CGI server extension does not create separate process for each request, instead the CGI server extension lives on web server, loaded in memory, ready to service requests. Server extensions can take many forms, such as Java Servlets, Active Server Pages (ASP) pages or ColdFusion. (Peng,
2003)
1.5.2.3 Mixed solutions
In everyday practice, a mixture of both server-side and client-side extensions is often used to benefit from advantages of both. (Brown and Kraak, 2001)
21 Almost all major GIS vendors came up with some mixed mapping publishing solutions. ESRI, for instance, uses its Arc View Internet Map Server (ArcIMS), which is an
ArcView extension which “enables CGI-compliant commands to be received from the browser. ” (Brown and Kraak, 2001) ArcView processes command and send to browser bitmap images. On the client-side, MapCafé, the Java applet is used to imitate ArcView interface in browser. (Brown and Kraak, 2001)
Figure 5: ESRI's mixed publishing solution using ArcIMS on server and MapCafé plug-in in client, source: (Brown and Kraak, 2001)
1.6 Distribution of geographic data
With great amount of geographic data being collected and stored, it is obvious that these data cannot be stored at one location. Instead, the model of distributed geodatabases has been adopted. In this model, different datasets can be kept in different places, providing the standardized way of accessing datasets exists and developers are able to combine
22 different data in their application. That is when web services come into play.
1.6.1 Web services overview
Web Service is a way of providing service and sharing data between different computer machines over network. Each web service can provide many kinds of informations and types of operations. To allow machines calling the service (client machine) to specify request, web service defines a set of parameters. By setting these parameters, client machine lets machine operating web service know what kind of information or operation is interested, for what kind of data etc. Applicable parameters are specify in Web Service technical specification which describes precisely the way communication should be carry out. (Webopedia, 2010a)
On the whole, web service presents a standardized interface which replaces diverse proprietary formats used with different systems – e.g. server-systems – with standardized formats, thus allowing for enhanced interoperability. (Webopedia, 2010a)
23 2. CARTOGRAPHIC VISUALIZATION ON WEB
Different ways of conceptualizing, storing and displaying geographical information have been presented in the previous chapter. This chapter offers a brief introduction to principles of techniques used for building complex cartographic visualizations from geographic data.
2.1 Web Map Service
“A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information.” (Open Geospatial Consortium, 2006a)
2.1.1. Principles of WMS
WMS mostly deliver maps, portrayals of geographic information, in the form of bitmap images. However, it can also produced graphical elements, such as SVG and else.
Interface for requesting data from WMS is defined by The OpenGIS® Web Map Server
Implementation Specification. The standard sets for WMS two obligatory and one optional operations described in the table below. (Open Geospatial Consortium, 2006a)
24 Table 1: Types of operations defined by specification by WMS, source: (Open Geospatial Consortium, 2006a)
Operation Name Type Description
GetCapabilities Obligatory gives information about service capabilities, so-called service-level metadata
GetMap Obligatory produces images of geographical data with well-defined spatial orientation, geo-referenced
gives information about specific feature displayed on the GetFeatureInfo Optional map
2.1.2. Mechanics behind WMS
Each service is invoked by HTTP request made by client, which is often web browser.
The request uses GET method of HTTP protocol and consists of two parts. The first part specifies the location of WMS service, the second part specifies WMS parameters which the machine running web service uses to generate correct response. (Open Geospatial Consortium,
2010c)
Figure 6: URL of the web service with highlighted location of service (red part) and parameters (blue part)
2.1.3 GetCapabilities, GetMap and GetFeatureInfo services
The GetCapabilities service serves the purpose of giving client detail information about service capabilities so that client can construct valid and meaningful requests. It sends back XML document which describes query parameters, layers that can be obtained, responsible party and many others. (Open Geospatial Consortium, 2006a)
25 Table 2: Mandatory parameters and their values required for the GetCapabilities request (Open Geospatial Consortium, 2006a)
Request Parameter Value Description
Request “GetCapabilities” Request name
SERVICE “WMS” Service type
Three non-negative integers, VERSION seperated by decimal points (e.g Request version 1.2.3)
MIME type string (e.g. image/jpeg, FORMAT Output format of service metadata image/png)
UPDATESEQUENCE Either string or integer Sequence number or string for cache control
The GetMap service is major workhorse of WMS as it produces images of geographic data. It is an essence of WMS and it is likely to be invoked the highest number of times. http://geoportal.cenia.cz/wmsconnector/com.esri.wms.Esrimap/cenia_arccr_nad ?request=getMap&service=wms&version=1.3.0&layers=0,1,3,4,6,7,8,9,12,14,15, 16,17,18,19&srs=EPSG:4326&bbox=16.45,49.1,16.75,49.3&format=image/png&width =600&height=400 Code example 2: Sample GetMap WMS request to CENIA mapping server which returns PNG image (600x400px) with layers specified by LAYERS parameeter for the area specified by BBOX parameter
Figure 7: Returned PNG image as the result of request at Code example 2.
26 Table 3: Mandatory parameters and their values required for the GetMap request, source: (Open Geospatial Consortium, 2006a)
Request Parameter Value Description
Request “GetMap” Request name
Three non-negative integers, VERSION seperated by decimal points (e.g Request version 1.2.3)
LAYERS Comma-separated list of layer names Layers to send to client
Four comma-separated numbers for BBOX min X, min Y, max X and max Y Area of interest returned map will cover with no gaps coordinates respectively
Sting in format namespace:identifier CRS Coordinate reference system (e.g. EPSG:4326)
Comma-separated list of styles, one STYLES Rendering styles for individual layers per requested layer
WIDTH Number Width in pixels of returned map
HEIGHT Number Height in pixels of returned map
MIME type string (e.g. image/png or FORMAT Format of returned map image/jpeg)
The GetFeatureInfo service is optional and might not be available for all WMS providers and all layers. Its purpose is to provide information about specific features. Most commonly, the service enables users to query additional information about features which have been visualized with the previous GetMap request. (Open Geospatial Consortium, 2006a)
27 Table 4: Mandatory parameters and their values required for the GetFeatureInfo request, source: (Open Geospatial Consortium, 2006a)
Request Parameter Value Description
Request “GetFeatureInfo” Request name
Three non-negative integers, VERSION seperated by decimal points (e.g Request version 1.2.3)
determined by map request map request part Copy of the GetMap request parameters parameters
QUERY_LAYERS Comma-separated list of layer names Layers to be queried
INFO_FORMAT MIME string type Returned format of feature information
I Integer x coordinate in pixels of feature
J Integer y coordinate in pixels of feature
2.1.4. WMS servers
To provide WMS services, spatialy-enabled servers need to be present to handle display and querying of large geographic databases and generate standard-conforming results. These servers might be both open-source, such as Mapserver or Geoseorver, and close-source, such as ArcIMS or GeoMedia. (Map Server, 2010), (Geoserver, 2010)
2.1.5. Geospatial Web
The idea of Geospatial Web dates back to 1998, when former U.S. Vice President Al
Gore proposed the need of a “multi-resolution, three-dimensional representation of the
28 planet, into which we can embed vast quantities of geo-referenced data.” (The Geospatial Web,
2007) The basic idea can be summarized as a possibility to link all the data available on the
Internet with their location. In this manner, users could search data not only by reference to entered keywords, but also by specifying location. Therefore, the Geospatial Web can be seen as spatially enabled Google search engine. The original idea gained much more attention with the come of virtual globes as Google Earth and NASA World Wind as well as mapping websites Google Maps, Yahoo Maps and others. (The Geospatial Web, 2007)
2.2 Symbology encoding language and symbology layer descriptor
Although WMS specification provides basic styling options with the STYLE attribute, it does not provide developers with possibility of defining custom styles and styling rules. To compensate for this, and enable more comprehensive style control, the Symbology Encoding language (SE) and Style Layer Descriptor profile specifications for WMS (SLD) were created.
2.2.1. Symbology Encoding language
OGC Symbology Encoding language is in its specification defined as “the format of a map-styling language for producing georeferenced maps with user-defined styling. “ (Open
Geospatial Consortium, 2006b) Its specification used to be part of SLD profiles specification for WMS but was separated later on so that it would become independent of any specific service. (Open Geospatial Consortium, 2006b)
SE is XML-based language and it defines elements for styling both basic types of geographical data, features and coverages. The core of SE language is represented by symbolizers which “describes how a feature is to appear on map. “ (Open Geospatial
29 Consortium, 2006b) There are five basic types of symbolizers: line, polygon, point, text and raster, each with its own set of parameters to describe styling. (Open Geospatial Consortium,
2006b)
To control which symbolizers are used in different situations, SE introduces rules.
They determine maximum and minimum scale of map for which given style is applied, for instance, roads can be displayed as simple lines with small map scales and more complex lines with larger map scales. Additionally, rules can contain filters, used to select feature to style by value of their attributes. For examples, roads with two or more lines can be displayed as thicker in comparison with one-line roads. (Open Geospatial Consortium, 2006b)
2.2.2. Styled Layer Descriptor
While SE language allows developers to specify their own custom styles for geographic portrays, they also need to instruct server to use these styles. That is when SLD comes into play.
SLD is a profile describing interface for styling WMS outputs, as well other OGS Web services outputs, using SE language. If WMS provider decides to implement SLD profile into their WMS service, it offers its users possibility to apply custom styles to geographical data, thus granting them much finer visual control over received portrays in comparison with basic WMS implementation. WMS with implemented support for SLD is often called SLD- enabled WMS. (Open Geospatial Consortium, 2006c)
SLD-enabled WMS supports an optional DescribeLayer operation which returns description of feature type of the queried layer. Developers use this description to explore layer's attributes and build styling rules accordingly. (Open Geospatial Consortium, 2006c)
30 To facilitate user interpretation of map, developers can call optional
GetLegendGraphic operation to obtain legend with samples of rendering of layers with custom styling.(Open Geospatial Consortium, 2006c)
Developers describe custom styles with XML file in which they select layers and feature within layers for styling as well as define styles to be applied. The real value of user- styles comes from the ability to store these files independently from server data in an interchangeable format, which allows for their multiple usage across different applications.
(Open Geospatial Consortium, 2006c)
2.4 GML vs. SLD
It is vital to emphasis the difference between GML described in chapter 1.4 and SLD from the chapter above.
GML defines geographic feature in an conceptualized abstract form. It represents real world data. Objects defined with feature element correspond to real-world objects. “GML is first and foremost about geographic-content representation.” (Galdos Systems Inc., 2007)
Although GML offers the Map presentation styling rules, its purpose is to carry information about occurrence of geographical features, their attributes and relations with each other rather than purely presentational information. SLD on the other hand does not provide means of representing geographical objects. Its purpose is to define styling rules for geographic content into different types of visualization. (Galdos Systems Inc., 2007)
The both formats can work in conjunction, GML can represent geographical features which are later on visualized and displayed according to SLD styling rules. However, there is a recently emerged language which handles both tasks, representing geographical content
31 and its visualization as well.
2.4.1 Keyhole Markup Language
Keyhole Markup Language (KML) is XML-based language which has been developed by Keyhole, Inc for Keyhole Earth Viewer. The company has been later on acquired by Google and first viewer supporting KML has been renamed to Google Earth.
(Galdos Systems Inc., 2007)
Figure 8: The Google Earth application capable of displaying KML, source: [http://robertclewis.files.wordpress.com/2008/05/google-earth.jpg ]
As implied above, KML uniqueness lays in its ability to represent geographical features themselves as well as the way they will be visualized. It is directly related to GML as it uses geometry defined in concordance with GML 2.1.2. (Galdos Systems Inc., 2007) Although it does not feature styling rules like SLD, SLD can be used to style GML to produce KML.
According to feature type and attributes, styling rules will be combined to produce a KML style element with specified id, which can be later on referenced within given feature by the
32 styleUrl attribute. Unlike many other formats, KML can also control user's navigation by specifying where to go and look. (Galdos Systems Inc., 2007)
Even though KML was originally developed by private enterprise, it was massively adopted by many software developers and, partly because of the huge popularity of the
Google Earth application, has been recognized as the OGC implementation standard.
(Galdos Systems Inc., 2007)
33 Code example 3: Sample KML file with styling of a polygon using the styleUrl attribute, source: [http://code.google.com/apis/kml/ documentation/kml_tut.html]
2.5 Filtering encoding
To provide even finer control over visualization of different features displayed on
WMS portrayals, filter encoding specified by the OpenGis Filter Encoding Standard (FES) has been introduced. Filter encoding, again XML-based language, utilizes filter expressions to define conditions feature are tested against. If feature fulfills given condition, it is selected to subset returned by server. (Open Geospatial Consortium, 2005)
2.5.1. Operators
Filter expression can contain three types of operators used to create filters. Logical, spatial and comparison. (Open Geospatial Consortium, 2005)
Spatial operator requires the geometry of given feature to satisfy certain spatial relationships (e.g. equal, touch, intersect or overlap with some other feature geometry).
Comparison operator allows to select features based on values of any chosen properties using standard mathematical comparison relations (equal, less than, greater than and else).
Logical operators (AND, OR or NOT) allows for combination of multiple expression to create really complex conditions. (Open Geospatial Consortium, 2005)
Besides that, FES supports also arithmetic operators which can encode simple arithmetic operations (add, subtract, multiple etc.) with property values. (Open Geospatial
Consortium, 2005)
34 3 PRINCIPLES OF WEB SERVICES
“A Web service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Web-related standards.” (W3C, 2004)
3.1 Web Services Architecture
Web service architecture is an abstract description of communication between the agent of service, provider entity (hereinafter server), and agent that wishes make use of the service , requester entity (hereinafter client), compromising the technology involved. (W3C,
2004)
As stated in the chapter 1.5.1, web service is way of automatized data retrieval from computers on the network. This retrieval is usually made by web application rather than humans and therefore, both request and response are encoded in the fashion easier to read for machines than a naked human eye. (W3C, 2004)
3.1.1 Architecture overview
The basic Web services platform are XML and Hypertext Transfer Protocol (HTTP).
XML is responsible for serializing requests from client and response from server and HTTP takes care of conveying both messages over the network. (Webopedia, 2010b)
35 Client uses lists of available web services called Universal Description Discovery and Integration (UDDI) to select appropriate service. The detail description of service capabilities in Web Services Description Language (WSDL) format is afterwards necessary to construct semantically correct request encoded by the Simple Object Access Protocol
(SOAP) which defines structure of the request and ensures that server understands correctly obtained request and produces correct response. (Webopedia, 2010b)
Figure 9: Web services architecture, source: [http://download.oracle.com/docs/cd/B14100_14/tour/qt/img/net2_01.gif]
3.1.2 Components
3.1.2.1 Universal Description Discovery and Integration
UDDI is essentially a registry based on XML which allows businesses to list themselves on the Internet. It advertises services available, describes their purpose and defines the way each service communicate with its clients. “By browsing a UDDI registry, a developer should be able to locate a service and a company, and find out how to invoke the service.” (OnJava, 2002)
36 UDDI consists of three components: white, yellow and green pages. White pages contain information about the business offering service and are used to find out more about already known service. Yellow pages provide classification of the service which can be searched according to categories, thus allowing for discovery of unknown services. Lastly, green pages describes technical specifications of the service. (OASIS, 2010)
In general, there are two different types of registries base on UDDI. Private, accessible within organizations, via intranet, and by business partners, via extranet and public, available across Internet to general public. (NetworkWorldFusion, 2002)
Table 5: UDDI data model contains three main elements, source: (OASIS, 2004)
Element name Description
businessEntity Name of physical company
businessService Name of service offered by company
bindingTemplate Instructions how to invoke service
tModel Identification of technical specification
3.1.2.2 Simple Object Access Protocol
SOAP is a very simple protocol enabling applications to exchange information with each other. It specifies structure of data send over HTTP from one machine to other. Data are structured in the machine-parseable format. This allows server to automatically decode request and client to easily handled response. The following figure show SOAP message
37 structure with the most important part of the message being body element as it contains the actual message. [45]
Figure 10: Schema of the SOAP message, source: [http://upload.wikimedia.org/wikipedia/commons/thumb/5/59/SOAP.svg/220px-SOAP.svg.png]
SOAP on itself is not concern with the details of establishing, maintaining and closing connection between machines. It is strictly focused on structure of data being transmitted.
SOAP delegates all other tasks to communication protocol it uses, HTTP. Client and server uses HTTP to communicate with each other. Communication is usually initiated by client which sends a request to server using Transmission Control Protocol (TCP). [45],
(W3Schools, 2010a), (About, 2010a)
38
3.1.2.3 Web Services Description Language
Purpose of WSDL is to describes web service, what types of operations are available and how they can be invoked.
39 Table 6: Major elements of WSDL document, source: (W3Schools, 2010b)
Element name Description
definitions Document's root element
types Definition of data types used by web service
message Definition of data elements used in operation
Describes web service, operations available and portType messages involved
binding Defines message format and protocol details
3.1.3 Types of web service
Todays Web offers virtually limitless number of different web services. Only OGC itself defines implementation standards for more than 10 web services. These services can work together to allow for sophisticated data retrieval, processing and transformation over the network, thus forming, when combined with datasets and legal framework to use them,
Spatial Data Infrastructure (SDI). An example of leveraging the possibilities of SDI is provided in the following use case.
3.1.3.1 Use case
The exemplary use case presents a scenario of a power line failure and resulting forest fire in vicinity of a military installation. It compromises a unit of fire fighters in charge of eliminating the fire and emergency operations center (EOC) responsible for delivering
40 supporting information. Information from EOC are collected at field by a staff officer who pass them to a chef of firefighters as needed. As a present days equipment of all actors does not always allow for full leveraging of web service capabilities, the ideal case with state-of- the-art technology is considered.
As the first step, EOC look up the suitable WMS sources of maps and satellite imagery which are afterwards used by fire fighters to navigate to the place of accident. As the company in charge of power lines is running WFS with its power line infrastructure, the path of power lines in given area are required as well and overlaid with the WMS imagery to help find the exact location of the failure.
Once the unite has arrive, it assesses the severeness and spread of the fire and send this information to EOC using the WFS transactions. EOC makes sure that changes made at field are propagated to all databases so that all other units heading to the place of accident have now the most up-to-date information.
As there is a military installation nearby with the stocked chemical materials which must be protected from fire at any cost, the military WFS service is used to retrieve locations of the storage places as well as the positions of military water reservoirs which might come in handy a little later on, if the fire continues to spread out and fire fighters water reserves start to running out. Unfortunately, the military WFS returns features in different spatial reference system, so the data need to be transformed via Web Coordinate Transformation
Server (WCTS) into the civil spatial reference system so that they could be overlaid with other data. All this is done by EOC so that firefighters received accurate and ready-to-use data.
The fire continues to spread much faster in certain parts of the forest, so the chef
41 instructs appointed officer to obtain information about susceptibility of the forest vegetation to fire throughout the region to determine the high risk areas. EOC receive request and invokes Web Processing Service (WPS) operated by the geological survey which executes the calculation of the fire susceptibility in the given area. This service needs elevation, land cover and other information to calculate the output, however, it is programmed to get this data from rasters obtained via Web Coverage Service (WCS) from the geological survey datasets. Therefore, EOC does not need to waste time looking for input data for the fire susceptibility analysis and can fully focus on delivering the right kind of information at the right time.
In this manner, different web services works can be used together to always obtain information required. (Open Geospatial Consortium, 2007e), (Open Geospatial Consortium, 2010d)
Figure 11: Use case diagram
42 3.1.3.2 Sensors
In the use case, there is a big part of the system which has not been covered, the sensors part. This part takes care of retrieving and calculating positions of all actors involved in the accident as well as location of the power line failure and else. The sensor parts includes usage of additional OGC implementation specification such as SOS, SAS, WNS and
SensorML as described in Chapter 1.4.4.3. (Open Geospatial Consortium, 2010a)
3.2 Web Feature Service
3.2.1 Principles
WFS allows client to “retrieve geospatial data encoded in GML from multiple Web
Feature Services. “ (Open Geospatial Consortium, 2002)
While WMS response provides client with simple images of spatial data, WFS response returns to client representation of individual geographical features in the chosen format with GML2 being preset as default. Acquired features can be afterwards modified in the client. Description of this modification, so-called transaction, is sent back to server which store required adjustments into the source database to update it in concordance with changes made by client. Interface for requesting data from WFS is defined by The OpenGIS® Web
Feature Server Implementation. (Open Geospatial Consortium, 2002)
43 Table 7: WFS operations, source: (Open Geospatial Consortium, 2002) Operation Name Type Description
DescribeFeatureType Obligatory generates a schema description of feature types
GetFeature Obligatory Retrieve feature in GML format. Can have GetFeatureWithLock variation.
GetGmlObject Optional retrieval of features and elements by ID
LockFeature Optional provides mechanism for locking features against eidts of other users
Transaction Optional generates transaction status description after modification of data
GetCapabilities Obligatory return service-level metadata similarly to the same operation of WMS
3.2.2 Mechanics
As the most common first step, client sends the GetCapabilities request to determine type of services available and a list of features types server can service. Based on feature types available, client invokes DescribeFeatureType which determines structure of request to either receive features (GetFeature or LockFeature) or transform features (Transaction).
(Open Geospatial Consortium, 2002)
The request is than send to a WFS server using HTTP. The request can be sent either with GET (encoded with keyword-value pairs) or with POST (encoded as XML document) method. (Open Geospatial Consortium, 2002)
44 http://mapserver.geogr.muni.cz/geoserver/wfs?TYPENAME=prepr %3Aedit_b_nastup_prostor&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG %3A32633&BBOX=469419.94760583,5374997.7293579,777279.94760583,5561477.7293579 Code example 7: Sample WFS request. Result of the request is shown in Attachment 1
Upon receiving the request, the WFS server reads it and, providing the request is valid, executes the request. If the request is invalid, server issues Service Exception to inform client that its request could not be processed. (Open Geospatial Consortium, 2002)
Usually only a subset of all features requestable from the service is required. There are multiple ways of how to restrict selection of features. The easiest way is to request features by their featureId which is the feature's unique identifier. The second, more complex way of selecting features involves the usage of OGC filter expressions as described in
Chapter 2.5. (Open Geospatial Consortium, 2002)
3.2.3 GetCapabilities, DescribeFeatureType, GetFeature, GetGmlObject LockFeature
The GetCapabilities operation of any WFS is very similar to the same operation of
WMS. It's divided into four sections described in the table below.
45 Table 8: GetCapabilites response structure, source: (Open Geospatial Consortium, 2002) Section name Description
Service section provides information about service itself
Capabilities section lists type of request server is able to service
contains all available feature types, feature Feature Type list operation and other info
Filter capabilities section defines supported filter operations
The DescribeFeatureType operation generates “schema description of feature types serviced by a WFS implementation. ” (Open Geospatial Consortium, 2002) The description determines structure of features returned with GetFeature and LockFeature operations as well as format in which modified features should be encoded in the Transaction operation.
(Open Geospatial Consortium, 2002)
The GetFeature operation is invoked to obtain a set of features from WFS. Each
GetFeature request contains one or more query elements, which describes query to use for selecting appropriate features. If there are multiple query elements, the results are afterwards concatenated to single request response. The structure of query element is described in the table below. (Open Geospatial Consortium, 2002)
46 Table 9: Query element structure, source: (Open Geospatial Consortium, 2002) Object Name Type Description
typeName Attribute indicates name of the feature to query
Enumerates feature properties to return with the response, if not present, PropertyName Element all properties returned
Limits number involved features to those in concordance with filter Filter Element expression.. If there is no filter element, all features are selected.
The GetGMLObject can be used to retrieve features according to their id. The
GetGmlObject element contains the GMLObjectId element whose attribute gml:id is used to retrieve the feature. (Open Geospatial Consortium, 2002)
As WFS allows for the client-side modification of features, severe inconsistencies can occur when multiple clients are editing same features at the same time. For these reasons,
WFS specification defines the optional LockFeature operation which enables developers to set temporary lock on features being edited, so that feature cannot be simultaneously edited from multiple places. The LockFeature element contains varying number of the Lock elements each of which sets lock on feature instance. Lock has an attribute expires, limiting maximum duration of the feature lock-in. (Open Geospatial Consortium, 2002)
3.2.4 Transaction
“The Transaction operation is used to describe data transformation operations that are to be applied to web accessible feature instances. “ (Open Geospatial Consortium, 2002)
In other words, the transaction operation allows for modification of features on the client side. The description of modifications made is then sent back to WFS server. The server itself afterwards processes the operation directly or it translates it into the target datastore
47 language and have the datastore execute the required operation on its own. The operation allows for creation of new features and modification and deletion of existing ones. The operation is optional, therefore, developers need to check GetCapabilities whether it is supported before trying to invoke it. (Open Geospatial Consortium, 2002)
The operation is encoded into the Transaction element which can contain any number of the Insert, Update and Delete elements described below. (Open Geospatial Consortium,
2002)
Table 10: Query element structure, source: (Open Geospatial Consortium, 2002) Element Name Description
Creates new feature. After successful insertion of the new feature, WFS generates Insert response with marked identifiers assigned to the new feature.
Describes modification of existing feature selected with the filter element. It Update contains one or more Property elements which specifies name of the modified property and its new value.
Delete removes features selected with the filter element
Additionally, if WFS supports LockFeature and GetFeatureLock operations, the value of the releaseAction attribute of the Transaction element can be specified, determining the control of locked features. (Open Geospatial Consortium, 2002)
48
3.3 Standardization of web services
3.3.1 Why standardization
According to International Organization for Standardization (ISO), standards are
“documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.” (Greenway, 2006) The use of standards ensures that certain pieces of technology will work as expected and will work together with other technologies adhering to the same standard. Plugs and sockets fitting into each other across different countries is a simple example of standardization. (Greenway,
2006)
49 The economic benefits of standards are numerous and have ever-rising importance in the globalized world due to considerably lower cost of porting different technologies across different regions and countries. Standardization also allows for much faster development of new technologies which are often leveraging many different existing technologies. (Greenway,
2006)
3.3.2 Web services standardization
In the realm of web services, standardization has a crucial role as web services are based on communication between different computers which might be using different hardware and software. Standardization of web services is therefore the way to “enable heterogeneous computer systems to interoperate efficiently.“ (Greenway, 2006)
In the world of geographic web services, governed by the OGC implementation specifications, standardization allows for development of complex mash-ups, applications which use combination of different web services to deliver rich content and functionality. “
The standards empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications. “ (Open Geospatial Consortium,
2010d)
The mission of OGC is to allow maximum usage of geospatial information in solving economic, environmental, social and other issues worldwide through the promotion of freely available standards for spatial data and services. These standards should remove obstacles while using data from different regions and services running on different platforms. (Open
Geospatial Consortium, 2010d)
50 4. USAGE OF WEB MAPS AND SERVICES ON WEB
As the usage of web maps and services is a quite broad topic extending far beyond the scope of the thesis, this chapter focuses exclusively on the usage from the perspective of the crisis management.
The different ways of leveraging capabilities of web maps and services are explored throughout the listing of functional and non-functional requirements for the exemplary application for the crisis management as described in Chapter 5.
4.1 Functional requirements
The functional requirements define application's operations which will enable user to
“perform some kind of function.” They specify what should application do (e.g. “The customer must place an order within two minutes of registering”). (Requirements authority,
2002)
In the following listing, the application's functions are not atomized, meaning only general functionality is described and many individual functions are implied rather than explicitly mentioned.
4.1.1 Visualization
The application shall visualize data from multiple sources. It will enable users to select from both WMS and WFS servers. The retrieved data will be transformed to common spatial reference system, if necessary, and overlaid in the map. The application will display
51 currently loaded layers in a comprehensive list where each layer can be temporarily turned off or permanently removed from map.
Through the ability to display data from multiple sources at once, the application shall support management of complex events when multiple events are occurring simultaneously (such as truck accident, resulting into an oil spill and fire and traffic jams on the interconnected roads).
The application shall provide means of map navigation, (zooming, panning and dragging) in the fashion similar to most commonly used map products (Google maps etc.).
The application shall also provide graphical legend explaining map symbols used in the map. The content of legend will be dependent on layers present in the map.
4.1.2 Editing
The application shall provide users with capabilities to manually edit WFS layers.
Users will be able to create new features and modify or remove existing ones. Although WFS supports attribute editing as well(Open Geospatial Consortium, 2002), the application does not need to provide this functionality. After finishing editing, users will be able to commit changes made to data to save them at the source database.
The application will enable user to select layer to edit and clearly and unambiguously identify currently edited layer in the list of layers as specified in Chapter 4.1.1.
52 4.1.3 Authoring
The application shall constraint access to editing capabilities as the function of user role. It will be connected to the authorization databases storing user accounts and determining user rights for each of the predefined roles. Users will be able to log-in via application interface to their account with assigned role, thus unlocking editing capabilities whenever applicable.
The application shall provide identification of logged user and his/her role as well as an option to log out.
4.1.4 Printing
The application shall provide capabilities of sending the image of currently displayed data to printing device, either actual printer, or conversion software (such as PDF printer,
PDFCreator and else). The image will featured not only spatial data, but also graphical legend, scale, title and annotation. User will be able to enter title and annotation text before submitting image to printing device.
4.2 Non-functional requirements
The non-functional requirements usually take form of a set of constraints or restrictions that define how the application should behave (e.g. “The customer must be able to access their account 24 hours a day, seven days a week. ”). (Requirements authority, 2002)
53 4.2.1 Performance
The application shall respond to user actions and communicate with any outside systems swiftly enough to allow for trouble-free usage even on slower networks which are to be expected when using the application at field. The application shall be bug-free not to pose any obstacles in leveraging its capabilities.
4.2.2 Usability
The application shall be user-friendly, meaning its operation will be simple and intuitive. All the most common tasks (adding new layers, editing data, printing) must be achievable within a few clicks. Even inexperienced users will need a little time to learn how to use it, in case the designed operator at field is injured or otherwise incapable of fulfilling required tasks and has to be replaced.
4.2.3 Extensibility
The application's architecture shall be suitable for easy introduction of new functional modules as required by end-users. The need for new functionality might arise from operational experience or newly available features of used technologies and it is necessary the application reflects upon these requests and changes.
4.2.4 Interoperability
The application shall be able to visualize all standard-conforming WMS and WFS data and to provide editing capabilities to all WFS data enabled for editing. The application will work with all modern browsers.
54 4.2.5 Resilience
The application shall be able to recover from internal errors so that it retains its functionality all the operational time. This means any of the failures that might occur when loading new datasets, editing, logging-in and else will not effect other functions which will be still usable. (Julian Browne, 2010)
55 5. APPLICATION FOR ON-LINE GEOSPATIAL DATA MANAGEMENT
To demonstrate the usage of OGC services (particularly WFS) in real world, an application allowing on-line management of geospatial data has been developed. It was created as a part of the Dynamic Geovisualization in the Crisis management research project at the Laboratory on Geoinformatics and Cartography at Masaryk University.
5.1 Research project
The crisis management deals with the decision-making in conditions of natural or humanitarian crisis, where any delay in taking an action can mean the lost of human lives.
One of the main issues under question is how to ensure that up-to-date informations are available in timely manner to all engaged parties.
5.1.1 Project description
The Dynamic Geovisualization in the crisis management project “deals with the process of transfer of geoinformation to the user.” (Dynamic Geovisualization in Crisis
Management, 2008) As each user has specific needs, level of expertise in the usage of cartographic products and conditions where are the products used, the members acknowledge that there is no one-size-fits-all solution and form of visualization needs to be adjustable depending on user. (Dynamic Geovisualization in Crisis Management, 2008)
Theoretical concepts are evaluated with different scenarios including one concerning the hazardous materials transportation (HAZMAT) with a case of one of the transportation vehicles having an accident. It presents a situation with unpredictable development and
56 many different units of the emergency service involved. The availability of up-to-date data directly from the place of accident is crucial. Only with the correct data, corresponding to reality, can the emergency service management take right decisions concerning how many additional units to dispatch and what measures to take.
5.1.2 Required functionality
To ensure obstacle-free flow of information from a place of accident to the emergency service central and vice versa, the way of visualizing and editing data at field needs to exist.
With this on mind, the requirements for client application are made. These requirements are in detail described in Chapter 4.
5.2 Architecture
The architecture propose for the HAZMAT scenario is based on the OGC implementation specifications and it can be divided into three subsystems, sensors and GPS subsystem, mapping and database subsystem and mapping client subsystem. The sensors and GPS subsystem is in charge of reporting HAZMAT vehicles position and potential occurrence of the accident to the mapping and database subsystem. The mapping and database subsystem stores data received from sensors and visualizes it. The mapping client subsystem presents visualized data to user and provide interface for exploring and manipulating data on-line. As the developed application is part of the mapping client subsystem, this subsystem will receive most attention in the rest of the chapter. (Řezník and
Hynek, 2009)
57 5.2.1 Sensors and GPS subsystem
This subsystem consists of transport and hit sensors which collects data about hazardous material transported and GPS locator collecting data about vehicle's position.
“The transporting vehicle has additional hardware device with sensors (i. e. anemometer, speedometer, and accelerometer), computer, GPS device, GPRS modem and LED display inside. “ (Řezník and Hynek, 2009) All the information are transferred to database via the wireless General Packet Radio Station (GPRS). The transfer is done using the User
Datagram Protocol (UDP). Unlike the Transmission Control Protocol (TCP) used by ordinary web traffic, UDP simplifies communication by not requiring both sides to negotiate before sending the data. This results in lower reliability of service but reduces significantly network usage which makes it ideal whenever communication is carried out on the slow connection. (Řezník and Hynek, 2009), (Kioskea, 2010)
5.2.2 Mapping and database subsystem
The sent information are stored in the PostgreSQL database with the PostGIS spatial extension. In the case study, one received record consists of 10 comma-separated values
(date, time, validity/non-validity of acquired information, WGS 84 latitude, WGS 84 longitude, altitude, speed of vehicle, wind direction, wind speed and quality of acquired information). This record is afterwards stored as database record with position and additional attributes. (Řezník and Hynek, 2009)
Once data are stored, they are visualized by mapping server represented by
Geoserver. The server queries database and data received sends to client either via WMS or
WFS responses. WFS communication between server and client takes places whenever user needs to visualize and edit individual geographic features. (Řezník and Hynek, 2009)
58 In the case study, its capabilities are enhanced with contextual cartographic service
(CCS). CCS takes care of choosing appropriate content and symbology from the underlying map servers and sends to client contextual map based on the user's context and user's role.
CCS communicates with mapping server via WMS and SLD requests. (Kozel, 2007)
5.2.3 Mapping clients subsystem
This subsystem is in charge of providing visualization of the spatial data to users and it is composed of two separate clients, mapping client and editing client, the developed application.
5.2.3.1 Mapping client
This client is ”an ordinary WMS client application with contextual service visualizing spatial data received from the server subsystem plus adding spatial data from other databases – such as dangerous chemical materials, critical infrastructure, technical infrastructure.” (Řezník and Hynek, 2009) Additionally, it displays orthophoto imagery obtained via WMS operated by Czech Environmental Information Agency (CENIA). Its purpose is to visualize location and status of hazardous material overlaid over chosen contextual and/or WMS layers. (Řezník and Hynek, 2009)
5.2.3.2 Editing client
This client can, similarly to the mapping client, display contextual service data and additional WMS layers from different sources.
More importantly though, it can visualize WFS layers. In these layers, users can
59 create new features or edit or delete the existing ones. The editing client “is primarily designed for the officer in charge at the field when a hazardous materials transportation accident occurs.” (Řezník and Hynek, 2009) It allows data stored in database to be updated from the field so that every unit can retrieve from database up-to-date information corresponding to the recent development.
To ensure that information are updated only by authorized personnel, the client requires user to log- in to allow any editing operation to take place. There are three user roles: admin, chef and user. For each user role, different editing rights can be specified.
Lastly, client's print module allows to transform visualization on screen into bitmap image with displayed legend, title and additional notes, thus creating a map of current situation. The technical specifications and implementation details of the editing client are described in Chapter 5.3.
60 Figure 12: Architecture of the HAZMAT scenario
5.3 Implementation and challenges
5.3.1 Implementation
The exemplary application has been developed as HyperText Markup Language
(HTML) page with JavaScript driven functionality and behavior and server logic written in the HypertextPreprocessor (PHP) language.
61 For the time being, the application is accessible at the following address:
http://mapserver.geogr.muni.cz/wfs-t/zdenek/
5.3.1.1 Used technologies and frameworks
The basic application structure is coded in HTML, by far the most popular publishing language of the World Wide Web. Page's basic building blocks are wrapped with HTML tags which give each element semantic meaning. (W3C, 1999)
As the application has to be responsive to users' actions, it contains logic written in the JavaScript scripting language. The JavaScript scripts are run in web browsers and allows for development of dynamic and interactive web pages. (Castledine and Sharkie, 2010)
JavaScript is supported by the vast majority of browsers. Unfortunately, particular implementation may vary from browser to browser. This inconsistency makes it somewhat hard to develop applications with the cross-browser functionality. (Castledine and Sharkie,
2010)
To compensate for this, the exemplary application has been developed using the jQuery library (version 1.3.2.) which provides not-only cross-browser support, but also other features facilitating the JavaScript developments. Additionally, the jQuery UI extension is used to avoid the necessity of developing commonly used user interface elements, such as dialog boxes, from scratch. (Castledine and Sharkie, 2010)
The editing client receives and visualize data from the mapping and database subsystem using the Open Layers framework. This framework “can load data from various sources, such as WMS (and WFS) servers, Google Maps, Yahoo! Maps, World Wind servers and many others.” (Řezník and Hynek, 2009) Open Layers provides unified interface for
62 displaying data from different mapping servers using different standards, and as such, considerable simplifies development of mapping applications. What makes Open Layers an obvious choice for the editing client is its native support for WFS data editing. (Řezník and
Hynek, 2009)
Because JavaScript is unsafe for any operations requiring certain level of security, all the source files are transmitted to the client-side and are easily accessible to users, the operations related to user authorization are executed on the server. In this manner, their inner logic is concealed from misbehaving users intending to compromise the application security. In the developed application, the PHP language is used for script validating the user's log-in information.
5.3.1.2 Application mechanics
On startup, the application requests default context layers. Based on user selection of additional layers to display, the application sends request either to Geoserver or third-party mapping servers to obtain data.
63 Figure 13: Cross-functional diagram of the visualization part of the editing client
On user log-in, the application sends entered user name and password to PHP script on server, which determines whether the log-in information are correct and sends result together with the role user is assigned. Based on the role, application switches to appropriate state, either allowing only viewing of WFS data, or allowing editing as well. 1
All the data modifications made by user in browser are not committed to Geoserver, and therefore not projected into source dataset, until user decides to do so by clicking the
Save icon. The application submits to Geoserver WFS-T transaction document with description of modifications. The document gets parsed and, if no issues are encountered, changes get projected to database. The application receives back notification about the status of modifications and about any possible errors that might have occurred during transaction.
1 For the purpose of experiment testing as described in Chapter 6, all user roles has been granted all editing rights.
64 Figure 14: Cross-functional diagram of the authentication part of the editing client
Figure 15: Cross-functional diagram of the editing part of the editing client
65 5.3.1.3 Class structure, coding style
Although JavaScript is not purely object-oriented language, it does not feature classical class-based inheritance as many others object-oriented languages (JAVA,
ActionScript 3.0), the class inheritance can be simulated with the prototype-based model.
Therefore, the application is object-oriented with every functional element corresponding to one class.
All the classes are in the predefined namespace LGC.client. The base class is
Application. The Application object is created once the page finishes loading and it takes care of initializing all the other needed objects. It is also responsible for the most top level behavior as displaying dialog boxes, setting application mode and else.
All the map related functionality is managed by the MapHelper class. Logging-in is handled by the Authentication class, which makes AJAX (Asynchronous JavaScript and
XML) calls with user identification information to PHP scripts on server which determine their validity.
All the dialog boxes inherits from the Dialog class. The DialogAddWMS and
DialogAddWFS classes additionally have common behavior inherited from the
DialogAddData class.
All the custom JavaScript files are stored in the scripts folder. This folder also contain some additional subfolders with classes related together, such as combos, context and else, thus simulating package structure of other languages (JAVA, ActionScript 3.0).
The jQuery library and related files are stored in the jquery folder.
66 All the PHP scripts and CSS styles are contained within the phpScripts and CSS folders respectively.
The admin folder contains the users.xml file which defines application users, their log-in passwords and roles.
The full source-code is available at the CD enclosed with the thesis (Attachment 6).
5.3.1.4 User interface design
The application's layout is divided into four parts as shown in Figure 16.
At the top bar, there is section for adding data, with two buttons for WMS and WFS servers, section for editing data, section for printing, context section, with two combo boxes for choosing appropriate context, section for logging-in and overview map.
At the left panel, there is a list of currently displayed layers with possibility to either switch off layer temporarily or to remove it completely. If the user is logged-in and some layer is selected for editing, this layer is marked with a red border. Additionally, if WFS layer features some symbology, the symbol is displayed as well.
At the right panel, there is legend for the current displayed context. The images of legend are obtained via the GetLegendGraphic request.
The most prominent section between left and right panel contains map itself. It also
67 features the default OpenLayers zoom and pan control and editing toolbar at the top-right, in case the application is in editing mode.
All the temporarily displayed dialog boxes share the same layout with close icon at the top-right and action button at the bottom-left. They are always displayed horizontally and vertically centered.
Figure 16: Basic application layout
5.3.2 Challenges
During the application development, several issues emerged and were handled with the varying level of success.
68 5.3.2.1 Cross-browser compatibility
The first version of the editing client was successfully tested in the Mozilla Firefox
(versions 2 and 3) and Opera 9. However, the content editing functionality did not work correctly in Internet Explorer (IE). (Řezník and Hynek, 2009) Therefore, this initial version has been replaced with the second version, which supported all major browsers (IE, Mozilla
Firefox, Google Chrome, Opera). Some measures needed to be taken to account to reflect differences between browsers behavior.
Until the Internet Explorer 7 release, the most widely used browser featured the Box
Model Bug. While most other browsers understand the CSS properties width and height as the size of HTML element without any possible margins or borders added, IE 5 and IE 6 in the quirk mode2 take value of the given properties as size of the element including any margins and borders assigned to the element. In other words, in non-IE browsers, element's content will always have size set by the width and height properties. In IE browsers prior to
IE6/strict though, the entire element's size will always correspond to set width and height, therefore scaling down element's content whenever borders and/or margins are applied. To compensate for this inconsistency, the script responsible for setting correct dimensions to application elements, and creating application desired layout, sets different widths according to a browser used. (About, 2010b)
The biggest challenge posed by the inconsistent cross-browser behavior was revealed during the development of the print module, which would allow users to print visualized data as an image. The base context layers are displayed with two independent calls to context server, therefore resulting in two transparent PNG images being displayed. However, for
2 The IE browser can run in different modes. The quirk mode provides backward compatibility for pages designed for older browsers. (About, 2010b)
69 some reason, the Internet Explorer page printer (regardless of a version used) cannot print transparent PNGs correctly. It always fills transparent parts of an image with white color, thus resulting in upper PNG obscuring entirely the second PNG beneath. To overcome this drawback, and not to change entirely the architecture of the application, when invoking print module on Internet Explorer, additional call to the context server is made and the two PNG images with context data are replaced with a new one, displaying the very same data as a single image.
5.3.2.2 Transformation inaccuracies
The application combines many different data from different sources. It visualizes data from custom in-house mapping server together with orthophoto obtained from CENIA.
The CENIA orthophoto layer is stored in S-JTSK (the Czech national coordinate system, unofficial EPSG 10267). Data in in-house database are stored in the UTM projection (EPSG
32633 and EPSG 32634). The editing client uses the WGS 84 coordinate system (EPSG 4326).
As a result, both the data from CENIA and in-house mapping server need to be transformed from their respective projections to WGS 84. However, as the data are stored in different coordinate systems, the different equations are used for the transformation to WGS 84. The used equations have different parameters, thus resulting in data being shifted in relation with each other. The realized shift of identical points was up to 20 meters. (Řezník and Hynek,
2009)
The solution for the transformation inconsistencies lays in changing the parameters of transformation to make data from different sources fit nicely together. This solution has not been tested during the application development. (Řezník and Hynek, 2009)
70 5.3.2.3 Complex symbology
The application uses symbology which is not dependent on scale. “Most features are visualized as points even though at large scales (i.e. up to 1:5000), it would be better to represent them as the polygon features.” (Řezník and Hynek, 2009) The features in question, such as the helicopter landing place, should change at certain scale to polygon areas to better reflect reality and provide sufficiently detailed information for the current scale.
The strict rules for feature symbology and scales, which would allow for such an advance visualization, were not tested during the application development. (Řezník and
Hynek, 2009)
71 6.CONCLUSION
6.1. Management summary
As a part of the Dynamic Geovisualization in the Crisis management research project at the Laboratory on Geoinformatics and Cartography, an application for on-line editing of geospatial data has been developed. The application allow for visualizing data stored in different databases, creating new features or editing and deleting the existing ones and storing the modification to the source databases. It represents part of the architecture for data management in the scenario concerning HAZMAT. (Řezník and Hynek, 2009)
The HAZMAT architecture and the developed application were successfully tested during the field experiment testing in November 2008. A mobile outpost for collecting and modifying data was established at the place of crisis. The data from the field were received and modified using the three different types of Internet connection (GPRS, satellite antenna and Wi-Fi “umbrella”). The emergency operational center was simulated at the Laboratory on geoinformatics and cartography where data updated from the field outpost were visualized and checked for inconsistencies. Both the mapping and editing clients worked without serious problems which would put obstacles in using the applications. (Řezník and
Hynek, 2009)
A few minor problems occurred during the field testing. Some layers, such as orthophotos, automatically turned off at certain scales. More complex, scale-dependent symbology was missing as mentioned in Chapter 5.3.2.3. (Řezník and Hynek, 2009)
72 6.2 Further development
For the further development, additional scenarios should be created to test functionality of applications and efficiency of architecture in different conditions to reveal potential pitfalls and limits. These scenarios could involve the transportation of chemical materials or floods.
The scenario has been tested only with a single user editing data at the time.
However, in reality, multiple users are likely to be logged-in and participate in content- editing. But what happen if two users edit the same feature at the same time? Only edits of the user who sends data to database first are actually stored. In future versions, some form of feature lock should be introduce to allow only single user at the time, to edit a given feature, thus preventing the lost of data edited from multiple users.
Whenever the situation in the place of crisis is rapidly evolving, data are bound to change over time. However, only few units at field will actually remember, or have time, to refresh application regularly to update newly edited data. Therefore, future versions of application should feature script, which would call with the set interval server for possible modification of data, thus keeping visualized information in concordance with the state of the source database.
Above all, the further proliferation of collaboration with the Integrated Rescue
System of Czech republic is desirable, as its units will be using the application created with the help of prototypes developed as a part of the Dynamic Geovisualization in the Crisis management research project.
73 Abbreviations list
AIXM - Aeronautical Information Exchange Mode
AJAX - Asynchronous JavaScript and XML ArcIMS - ArcView Internet Map Server ASP – Active Server Pages CENIA – Czech Environmental National Information Agency CGI – Common Gateway Interface CCS – Contextual cartographic service CSS - Cascading Style Sheets ESRI – Environmental Systems Research Institute FES - Filter Encoding Standard GIF - Graphics Interchange Format GIS – Geographic Information System GML – Geography Markup Language GPRS – General Packet Radio Station HAZMAT - Hazardous materials transportation HTML – HyperText Markup Language HTTP – Hypertext Transfer Protocol IE – Internet Explorer ISO - International Organization for Standardization JPEG - Joint Photographics Experts Group KML - Keyhole Markup Language O&M - Observations & Measurements Schema OGC - Open Geospatial Consortium PNG - Portable Network Graphic SAS - Sensor Alert Service SDI – Spatial Data Infrastructure SE – Symbology Encoding
74 SensorML - Sensor Model Language SLD - Styled Layer Descriptor SOAP - Simple Object Access Protocol SOS - Sensor Observations Service SPS - Sensor Planning Service SVG - Scalable Vector Graphics SWE – Sensor Web Enablement TCP - Transmission Control Protocol TransducerML or TML - Transducer Markup Language UDDI - Universal Description Discovery and Integration UDP – User Datagram Protocol VML – Vector Markup Language W3C - World Wide Web Consortium WCS - Web Coverage Service WCTS - Web Coordinate Transformation Server WFS – Web Feature Service WMS – Web Map Service WNS - Web Notification Services WPS - Web Processing Service WSDL - Web Services Description Language XML - Extensible Markup Language
75 REFERENCES
Printed documents
[1] LONGLEY, P. A., et al.: Geographic Information Systems and Science. Chichester, England : John Wiley
& Sons, 2005. 534 p. ISBN: 978-0-470-87001-3
[2] PENG, Z.R.: Internet GIS. Hoboken, New Jersey : John Wiley & Sons, 2003. 670 p. ISBN: 978-0-471-
35923-4
[3] BROWN, A., KRAAK, J.M.: Web Cartography. Oxford, UK : Taylor & Francis, 2001. 213 p. ISBN
074840869X.
[4] CASTLEDINE, E., SHARKIE, C.: JQuery: Novice to Ninja. [s.l.] : SitePoint, 2010. 300 p. ISBN
0980576857.
[5] ŘEZNÍK, T., HYNEK,Z.: Data Management in Crisis Situations through WFS-T client. In Proceedings of Cartography and Geoinformatics for Early Warning and Emergency Management. Brno : Masaryk
University, 2009. 9 p. ISBN 978-80-210-4796-9.
Electronic documents
[6] OPEN GEOSPATIAL CONSORTIUM: OpenGIS® Geography Markup Language (GML) Encoding
Standard [online]. 2007a [Accessed 2010-07-07]. Available at WWW:
[7] OPEN GEOSPATIAL CONSORTIUM: OpenGIS Styled Layer Descriptor (SLD) Implementation
Specification [online]. 2007b [Accessed 2010-07-07]. Available at WWW:
[8] OPEN GEOSPATIAL CONSORTIUM: Geography Markup Language (GML) 2.0 [online]. 2001
[Accessed 2001-07-07]. Available at WWW: 76 artifact_id=1034>. [9] BURGGRAF, D.: GML Overview [online]. 2005 [Accessed 2010-11-04]. Available at WWW: [10] OPEN GEOSPATIAL CONSORTIUM: Candidate OpenGIS® CityGML Implementation Specification [online]. 2007c [Accessed 2010-07-07]. Available at WWW: [11] OPEN GEOSPATIAL CONSORTIUM: OGC® Sensor Web Enablement: Overview And High Level Architecture. [online]. 2007d [Accessed 2010-07-07]. Available at WWW: [12] OPEN GEOSPATIAL CONSORTIUM: OpenGIS® Web Map Server Implementation Specification [online]. 2006a [Accessed 2010-07-07]. Available at WWW: [13] OPEN GEOSPATIAL CONSORTIUM: Symbology Encoding Implementation Specification [online]. 2006b [Accessed 2010-07-07]. Available at WWW: [14] OPEN GEOSPATIAL CONSORTIUM: OpenGIS Styled Layer Descriptor (SLD) Implementation Specification [online]. 2006c [Accessed 2010-07-07]. Available at WWW: [15] OPEN GEOSPATIAL CONSORTIUM: OpenGIS® Filter Encoding Implementation Specification [online]. 2005 [Accessed 2010-07-07]. Available at WWW: [16] OPEN GEOSPATIAL CONSORTIUM: OpenGIS® Web Processing Service [online]. 2007e [Accessed 2010-07-07]. Available at WWW: [17] OPEN GEOSPATIAL CONSORTIUM: Sensor Web Enablement WG [online]. 2010a [Accessed 2010- 11-08]. Available at WWW: 77 [18] OPEN GEOSPATIAL CONSORTIUM: Web Feature Service Implementation Specification [online]. 2002 [Accessed 2010-07-07]. Available at WWW: [19] GREENWAY, I.: Why Standardise? [online]. 2006 [Accessed 2010-07-07]. Available at WWW: [20] KOZEL, J.: Open Contextual Cartographic Visualization [online]. 2007 [Accessed 2010-12-07]. Available at WWW: [21] OASIS: Introduction to UDDI: Important Features and Functional Concepts [online]. 2004 [Accessed 2010-07-07]. Available at WWW: WWW pages [22] CHASTAIN, S.: About.com - Vector and Bitmap Images [online]. 2010 [Accessed 2010-07-23]. Available at WWW: [23] WEB STYLE GUIDE. Graphic file formats [online]. 2008 [Accessed 2010-05-10]. Available at WWW: [24] LRBABE. The state of cross-browser vector graphics [online]. 2009 [Accessed 2010-05-10]. Available at WWW: [25] W3C. About SVG [online]. 2010a [Accessed 2010-07-02]. Available at WWW: Graphics/SVG/About>. [26] W3C. Scalable Vector Graphics (SVG) 1.1 (Second Edition) [online]. 2010b [Accessed 2010-07-23]. Available at WWW: [27] THE REGISTER. Google to slip SVG into Internet Explorer [online]. 2010 [Accessed 2010-07-02]. Available at WWW: [28] OPEN GEOSPATIAL CONSORTIUM. OGC Seeks Comments on SWE Common Service Model Interface Standard [online]. 2010b [Accessed 2011-01-08]. Available at WWW: 78 [29] WEBOPEDIA. Understanding Web Services [online]. 2010a [Accessed 2010-07-02]. Available at WWW: [30] ADOBE. Flash Player Version Penetration [online]. 2010 [Accessed 2010-11-04]. Available at WWW: [31] JOBS, S.: Apple - Thoughts on Flash [online]. 2010 [Accessed 2010-11-04]. Available at WWW: [32] IEBLOG. SVG in IE9 Roadmap [online]. 2010 [Accessed 2010-11-04]. Available at WWW: [33] W3C. Vector Markup Language (VML) [online]. 1998 [Accessed 2010-11-04]. Available at WWW: [34] OPEN GEOSPATIAL CONSORTIUM. Web Map Service [online]. 2010c [Accessed 2010-07-07]. Available at WWW: [35] MAPSERVER. Introduction [online]. 2010 [Accessed 2010-07-07]. Available at WWW: [36] GEOSERVER. Welcome Geo server [online]. 2010 [Accessed 2010-07-07]. Available at WWW: [37] THE GEOSPATIAL WEB. Preface [online]. 2007 [Accessed 2010-07-07]. Available at WWW: [38] GALDOS SYSTEMS INC. GeoWorld: KML and GML Working Together [online]. 2007 [Accessed 2010- 07-07]. Available at WWW: [39] W3C. Web Services Architecture [online]. 2004 [Accessed 2010-07-07]. Available at WWW: [40] WEBOPEDIA. What is Web services [online]. 2010b [Accessed 2010-07-07]. Available at WWW: 79 [41] ONJAVA. UDDI [online]. 2002 [Accessed 2010-07-07]. Available at WWW: [42] OASIS. UDDI Version 3.0.2 [online]. 2010 [Accessed 2004-10-19]. Available at WWW: [43] NETWORKWORLDFUSION. UDDI is Yellow Pages of Web services [online]. 2002 [Accessed 2010- 07-07]. Available at WWW: [44] SATRAPA, P.: HTML v příkladech - Hypertext Transfer Protocol (HTTP) [online]. 1997 [Accessed 2010- 07-23]. Available at WWW: [45] W3SCHOOLS. SOAP Tutorial [online]. 2010a [Accessed 2010-07-07]. Available at WWW: [46] ABOUT. Simple Object Access Protocol - SOAP [online]. 2010a [Accessed 2010-07-07]. Available at WWW: [47] W3SCHOOLS. WSDL Documents [online]. 2010b [Accessed 2010-07-07]. Available at WWW: [48] OPEN GEOSPATIAL CONSORTIUM. About OGC [online]. 2010d [Accessed 2010-07-07]. Available at WWW: [49] REQUIREMENTS AUTHORITY. Functional and Non-Functional Requirements [online]. 2002 [Accessed 2010-12-27]. Available at WWW: [50] JULIANBROWNE. Systemic Requirements [online]. 2010 [Accessed 2010-12-27]. Available at WWW: [51] DYNAMIC GEOVISUALIZATION IN CRISIS MANAGEMENT. Introduction [online]. 2008 [Accessed 2010-07-21]. Available at WWW: [52] W3C. HTML 4.01 Specification [online]. 1999 [ Accessed 2010-07-21]. Available at WWW: 80 [53] ABOUT. Box Model Hack [online]. 2010b [Accessed 2010-07-21]. Available at WWW: [54] KIOSKEA. Differences between the UDP and TCP protocols [online]. 2010 [Accessed 2011-01-02]. Available at WWW: 81 ATTACHMENTS Attachments list Attachment 1 WFS request result from the Code example 7 Attachment 2 Exemplary WFS-T transaction Attachment 3 Application's user interface screenshots Attachment 4 Exemplary JavaScript class Attachment 5 Authorization database XML Attachment 6 – unattached CD with the application's source code and full text of the thesis. Attachment 1 - WFS request result from the Code example 7 Log-in dialog Add WFS data dialog Print module dialog Attachment 4 - Exemplary JavaScript class // LGC.client.DialogAddWMS extends Dialog_addData LGC.client.DialogAddWMS = function(selector){ var parent = new LGC.client.Dialog_addData("wms",selector,this.serverTitle,this.layerTitle,this.wmsServer,this. wmsLayers); //set inheritance jQuery.extend(this,parent); var that = this; dialog = this; this.serverTitle = lang(Brown and Kraak, 2001); this.layerTitle = lang(Castledine and Sharkie, 2010); this.wmsServer = ["",cenia._title,geogrMuniColor._title]; this.wmsLayers = ["Choose server first"]; this.selectServer = $("#dialogForm [name='server']"); this.selectLayer = $("#dialogForm [name='layer']"); this.selectServer.bind("change",function(){that.getLayer();}); $("#dialogForm").submit(function(){ var server = $(dialog.selectServer).val(); var layer = $(dialog.selectLayer).val(); mapHelper.addWMSData(server,layer,true); return false; }); this.getLayer = function(){ var server = this.selectServer.val(); var layer = this.selectLayer.val(); if(server != ""){ for(var i=0;i this.selectLayer.children().remove(); this.selectLayer.append(options); } } } else{ this.selectLayer.children().remove(); this.selectLayer.append(""); } } } Attachment 5 - Authorization database XML