Smartphone PPGIS for Oil Spill Information Exchange...Smartphone PPGIS for Oil Spill Information...

111
Kim Verup, John Morten Klingsheim, Simen Slotta, Weixiao Yang MTM – Master of Technology Management with specialization in Geoinformatics and Geoinformation Management 3. semester, 2013 Aalborg Universitet Smartphone PPGIS for Oil Spill Information Exchange

Transcript of Smartphone PPGIS for Oil Spill Information Exchange...Smartphone PPGIS for Oil Spill Information...

Kim Verup, John Morten Klingsheim, Simen Slotta, Weixiao Yang

MTM – Master of Technology Management with specialization in Geoinformatics and Geoinformation Management

3. semester, 2013

Aalborg Universitet

Smartphone PPGIS for Oil Spill Information Exchange

Title: Smartphone PPGIS for Oil Spill Information Exchange

Education: MTM – Master in Geoinformation Management

Theme: Open source and ESRI alternatives for smartphone GIS. PPGIS.

Project period: 1. February 2013 - 10. June 2013

Project team:

MTM group 3

Attendees:

……………………………………………..

Kim Verup

……………………………………………..

Simen Slotta

John Morten Klingsheim

……………………………………………..

Weixiao Yang

Counsellors: Supervisor: Henning Sten Hansen Secondary supervisor: Lise Schrøder Synopsis:

Educational organisation: Department of Development and Planning Aalborg University A.C. Meyers Vænge 15 2450 København SV 10. June 2013 Report information: Edition: 5 stk. Number of pages: 101 pages. Enclosures: A CD with this report, appendices, and used literature.

The purpose of this project is to test geographic information technologies in promoting oil spill information exchange with citizens. Two prototypes are developed on open source and ArcGIS Online platform respectively. Four personas are involved by testing field-reporting mock-ups and prototypes. In order to ensure and document the project progress and results, Use Cases together with personas, are created for user interactions and mastering the user requirements; agile is applied as project management tool; geodesign model is integrated in the information design process and establishes a basis for prototypes’ comparison. Challenges from both technologies and NCA organisation are discussed during the development. Major contribution of this project is confirmation of technological basis and possibilities for development of a cross-platform PPGIS Smartphone app concerning oil spills.

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Table of content:

Preface ................................................................................................................... 1

1 Introduction ..................................................................................................... 3

1.1 Oil spill clean-up operations .............................................................................................................. 3

1.2 A resume of “PPGIS – Borgerinddragelse ved olieforurening” ......................................................... 3

1.3 Problem statement ............................................................................................................................ 4

1.4 Content .............................................................................................................................................. 5

2 Project method ................................................................................................ 7

2.1 Agile methodology ............................................................................................................................. 7

2.2 Geodesign methodology ................................................................................................................... 8

2.3 Personas and Use Case methodology ............................................................................................... 9

2.3.1 Personas method ....................................................................................................................... 9

2.3.2 Use case modelling .................................................................................................................. 10

2.4 Flow model methodology ................................................................................................................ 10

3 User requirements ......................................................................................... 13

3.1 Requirements of information exchange .......................................................................................... 13

3.1.1 Information requested by citizens ........................................................................................... 13

3.1.2 Information requested by NCA ................................................................................................ 14

3.2 NCA’s Information procedures ........................................................................................................ 14

3.2.1 Oil spill reports ......................................................................................................................... 15

3.2.2 Oil spill situation and prognoses ............................................................................................. 16

3.3 Use case modelling .......................................................................................................................... 16

3.4 Data modelling ................................................................................................................................ 18

3.5 Personas .......................................................................................................................................... 20

3.5.1 Four personas .......................................................................................................................... 22

3.6 User Interface on a smartphone...................................................................................................... 24

3.7 Response on Mock-up Prototype .................................................................................................... 25

4 GI technology for smartphones ...................................................................... 27

4.1 Server technology ............................................................................................................................ 27

4.1.1 Web server .............................................................................................................................. 27

i

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

4.1.2 Web Map server ...................................................................................................................... 29

4.1.3 Map Transformation ................................................................................................................ 34

4.1.4 Database .................................................................................................................................. 36

4.1.5 Desktop GIS ............................................................................................................................. 40

4.2 Smartphone applications ................................................................................................................. 41

4.2.1 Mobile application with GIS features ...................................................................................... 41

4.2.2 HTML5 (Hypertext Markup Language) .................................................................................... 44

4.2.3 CSS3 (Cascading Style Sheet) ................................................................................................... 46

4.2.4 JavaScript ................................................................................................................................. 47

4.3 PPGIS interaction tools .................................................................................................................... 48

4.3.1 PPGIS and Crowdsourcing ....................................................................................................... 48

4.3.2 PPGIS and the Deepwater Horizon oil spill in the Mexico Gulf ............................................... 49

4.3.3 Other relevant GIS-applications .............................................................................................. 51

4.4 Technical challenges ........................................................................................................................ 53

4.4.1 Units in smartphones............................................................................................................... 53

4.4.2 Mobile GPS precision ............................................................................................................... 56

4.4.3 Mobile image quality ............................................................................................................... 58

4.4.4 Metadata for mobile images ................................................................................................... 59

4.5 Summary of GI technology .............................................................................................................. 60

5 Prototype ....................................................................................................... 61

5.1 Prototype requirements .................................................................................................................. 61

5.2 Open source based prototype ......................................................................................................... 62

5.2.1 Content - Open source prototype ........................................................................................... 63

5.2.2 System - Open source prototype ............................................................................................. 65

5.2.3 Interaction - Open source prototype ....................................................................................... 66

5.3 ESRI-based prototype ...................................................................................................................... 68

5.3.1 Content – ESRI prototype ........................................................................................................ 69

5.3.2 System – ESRI prototype.......................................................................................................... 71

5.3.3 Interaction – ESRI prototype ................................................................................................... 72

5.4 Testing prototypes on personas ...................................................................................................... 73

5.5 Testing prototypes on professional users ....................................................................................... 75

ii

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.6 Summary on prototype testing ....................................................................................................... 76

6 Discussion ...................................................................................................... 77

6.1 Handling the user requirements ..................................................................................................... 77

6.2 Organisational challenges ................................................................................................................ 78

6.3 Technology review and prototyping ................................................................................................ 80

6.3.1 Technology review ................................................................................................................... 80

6.3.2 Prototyping .............................................................................................................................. 85

7 Conclusion ..................................................................................................... 87

8 Proposals for further work ............................................................................. 89

9 Abbreviations ................................................................................................ 91

10 References ..................................................................................................... 93

Litterature: ................................................................................................................................................... 93

Webpages: ................................................................................................................................................... 95

Personal communication: .......................................................................................................................... 100

11 Appendices .................................................................................................. 101

iii

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Preface This report was prepared at 3 semester of the Master of Technology Management education in Geoinformation Management at the University of Aalborg. Through our work, we have found a suggested basis for the development for a Smartphone PPGIS for oil spill information exchange during oil spill clean-up operations after major accidents at sea.

The project group participants are involved daily in geographic information systems. In addition, we are engaged in the environmental and social consequences we have seen to be the result of the major oil spill accidents that have occurred in recent years, both in Scandinavia and worldwide.

We want to give a big thanks to all those assisting us with guidance in this work, especially thanks to Kjetil Aasebø and Silje Berger giving us knowledge on the Norwegian Coastal Administrations preparedness for acute oil spill, and testing our prototypes. Thanks to the two citizens contributing with their knowledge of citizen participation in oil spill clean-up from the last year’s major oil spill in Norway. Thanks to Landmålergården I/S for setting up a web server available for developing and testing, we look forward to take it into extensive use on the upcoming semester. Thanks to Bent Gaardsvig Kjeldsen for showing us the success of Miljøministeriet’s similar mobile application, and telling about their process and thoughts, which gave us a good start on the development.

Thanks to our supervisors, Henning Sten Hansen and secondary supervisor Lise Schrøder at the University of Aalborg, for challenging and guiding us on scientific work methods, and all the technical and procedural issues raised in our report. And finally, our thanks to Morten Fuglsang, giving us the most updated knowledge on development of GIS for smartphones.

To understand the environmental, social and economical consequences of major oil spills, and how oil spill clean-up operations are handled, we will recommend a movie published on Youtube that presents the oil spill clean-up operation after the Full City accident at Såstein southwest of Langesund 31. July 2009 – Link

Copenhagen / Arendal / Haugesund 10th June 2013

1

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

2

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

1 Introduction Based on interest from The Norwegian Coastal Administration (NCA), this report is presenting a suggested way to develop a Smartphone PPGIS (public participation geographical information system) to exchange information with citizens during oil spill clean-up operations.

1.1 Oil spill clean-up operations The last decade there have been four major accidents in Norwegian coastal waters causing major oil spills: the “Rocknes” in 2004, the “Server” in 2007, the “Full City” in 2009 and the “Godafoss” in 2011, all causing large clean-up operations (Boitsov, Klungsøyr and Dolva, 2013).

“Full City” grounded 31. July 2009 at Såstein southwest of Langesund. 293 tonnes of heavy oil leaked out and 75 km of coastline was contaminated, spread on approximately 200 locations in the archipelago southwest and east of Langesund. The initial clean-up operation lasted until November 2009, with final clean-up spring/summer 2010. 16 vessels were assisting the clean-up operation, including assistance from the Swedish coastguard, and approximately 1000 volunteers participated together with the standard available oil spill response groups1. The grounding of “Full City” caused a clean-up operation costing more than 234 million Norwegian kroner (PricewaterhouseCoopers, 2010), plus the environmental and economic damages.

The four major accidents in Norwegian coastal waters all caused high attention and engagement among local citizens. A public engagement is caused by both environmental and economic consequences. Large oil spills can especially cause deaths of seabirds and sea mammals, and economical losses for coastal businesses, as reviewed after the grounding of “Full City” (Boitsov, Klungsøyr and Dolva, 2013). Each incident however, is unique in terms of environmental impacts.

NCA is responsible for the national governmental oil spill response in Norway, and have established routines for involving volunteers in clean-up operations. Our report on citizen’s involvement during coastal oil spills “PPGIS – Borgerinddragelse ved olieforurening” (Verup et al., 2013) documented a requirement for a better information exchange between NCA and the general public, especially when oil spills contaminate large coastal areas.

1.2 A resume of “PPGIS – Borgerinddragelse ved olieforurening” The report on citizen involvement during coastal oil spills (Verup et al., 2013) is an analysis of user requirements after oil spill disasters. The analysis was performed by setting up an internet survey for the citizens and by interviewing the actors which are to minimize oil spills after accidents. The survey confirmed a high interest for a PPGIS based on Smartphone Technology. The survey also identified the requirements of actors and citizens, which should be satisfied.

1 The Norwegian governmental preparedness against oil pollution consist of a response unit in the NCA, and regional Intermunicipality response units (IUA – Interkommunale utvalg for akutt beredskap).

3

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

A Smartphone application for information exchange was found to have most interest after large oil spills, because after large oil spills, contaminated coast can be difficult to locate, and oil can be found many miles away from the origin of the oil spill. The pressure for information from citizens and media is also found to be high after large oil spills, and the clean-up operations can last for weeks and months. The smartphone was found as the best communication channel as citizens will usually have their smartphone available, and the smartphone camera can give updated pictures with attached info directly from the contaminated site. Checking existing map tools for smartphones also showed this as the most interesting interface for giving citizens updated information on oil spill situations and oil spill prognoses.

The following perspectives from “PPGIS – Borgerinddragelse ved olieforurening” is responded to in this report:

• A detailed analysis of NCA’s department for emergency response and their operational organisation is needed, to adapt a Smartphone PPGIS to its context (Chap. 3.2).

• Organisational challenges should be pinpointed by analysing NCA’s de facto information procedures, and evaluate need of changes in their procedures (Chap. 6.2).

• A survey of Smartphone GI (Geographical Information) technology and existing parallel systems are needed (Chap. 0).

• A description of the information architecture in NCA is needed to find best way to integrate with existing decision support systems (Chap. 3.2).

• The most critical elements for a system that should contribute to a better oil spill emergency response should be pointed, e.g. performance, stability, and user friendliness (Chap. 4.4).

• Light weight technical mockups must be developed to confront users (Chap 3.7).

1.3 Problem statement There are a lot of challenges in developing a Smartphone application that everyone should be able to like and even to use. Multiple operation systems (OS) and a large variety of user skills among citizens challenges the development and design (Castledine, Eftos and Wheeler, 2011), however in a world where the spatial awareness is increasing based on new technologies like Google Maps and Smartphone map applications, we will in the future see more and more applications including geolocation technologies. In this report we will examine the available technology for development of smartphone applications, and methods used for development, to suggest a way forward for developing a prototype of the Smartphone PPGIS for oil spill emergencies.

The issue of this project is to find a best way for development of the communication channel between NCA and the citizens. A communication system must also address the requirement of working in cross-country operations. The major topic is smartphone GIS (Geographical Information Systems), however web-GIS and desktop GIS should also be a part of the system, especially for NCA to verify and utilize oil spill reports.

The problem statement addressed in this project is therefore:

“With today’s technology, how can we best develop a Smartphone PPGIS for involving citizens to contribute to a better oil spill emergency response and clean-up operations after large oil spills”

4

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The term “large oil spills” here means oil spill situations taken over by national authorities (NCA) because of high potential of environmental damages and need of a considerable response, best handled on a national level.

To achieve an answer to the problem statement we have pointed out three major questions:

- How should we involve users and user requirements during a flexible and agile process to push the development in the right direction?

- How are the existing procedures and routines in NCA’s oil spill emergency response and what challenges should we expect for an implementation of the Smartphone PPGIS within NCA’s organisation, also including the requirement of cross country functionality.

- Which GI (Geographical Information) technologies are best to choose for our development of the required Smartphone PPGIS? Should we build on open source GIS, commercial GIS (commercial GIS here represented by ESRI software), or a combination?

1.4 Content This report is built up sequentially where the following chapters build on the text ahead, however single chapters can also be read isolated, and give an insight into the different subjects.

Chapter 2 contains all used methodologies, including methods used for making this report and methods to be used for the development process, including personas, Use case and Agile development. Chapter 3 is about personas interaction to effect on the mockup and prototypes, and the procedures used for information in major oil spill disasters. The chapter then describes the data model and flowchart to support development of a smartphone application. In chapter 4 existing solutions similar to the presumed Smartphone PPGIS are compared and handlings of other PPGIS-scenarios are presented. After this we dig into the technical challenges, and analyse the use potential of different setups. Coming to chapter 5, two light weight prototypes are presented, one for open source, and one based on commercial software. Personas are used for testing the prototypes and for a validation of the user interface, and interaction. As commercial software, products of ESRI2 (ArcGIS-software) are chosen as the option. In chapter 6 we discuss the applicable technologies and the feedbacks from our personas to support the right decision. Chapter 7 present the conclusions on a suggested best practice for development of the smartphone application for NCA’s oil spill emergency response and choices of technology. Then finally a proposal for further work is given in chapter 8.

The aim of this report is to have a clear conclusion about a preferred process for system development and which technology to be used, in order to get the required performance. The survey on technology and the tests with a mockup and light weight prototypes are performed to facilitate a future development of a full working prototype.

2 Environmental Systems Research Institute

5

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Chapter 1 Introduction

Chapter 2

Project method

Chapter 3 User requirements

Chapter 5

Prototype

Chapter 4

GI technology for smartphones

Chapter 6.1

Handling the user requirements

Chapter 6.3 Technology review and

prototyping

Chapter 6.2 Organisational

challenges

Chapter 7

Conclusion

Chapter 8 Proposals for further work

Chapter 3.2

Figure 1: Structure of this report showing the main chapter relations

DISC

USS

ION

6

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

2 Project method In this chapter the execution process of project will be described together with the methodologies and tools applied. As stated in Chapter 1.3, we have to tackle three major problems, shortly mentioned as user requirements from citizens and NCA; possibilities and challenges from the state-of-art technologies; best practice that suits our case. In the preparation phase of our project, we picked up different methods to every single problem. As our project includes software development, agile is chosen as management method, not only for the development process, but also for the whole project. In order to understand the user requirements from both citizens and NCA, we listen to the users carefully by applying personas and use cases methodology. As for the app development itself, geodesign model and flow model diagram methodology are used to evaluate and compare the results in different platforms. All these models integrated in this project work act as guidelines in their relevant parts. All the methods ensure the quality and extent of our project work.

2.1 Agile methodology The agile methodology is primary for software engineering development, but it has also been seen in other types of projects. Agile has over the past few years had a success, and therefore more and more project leaders stick to that. The method was constructed as a response to the traditional project methods, which normally is slower, comprehensive and often contains a lot of documentation and planning like larger IT (Information Technology) projects (Benyon, 2010). In addition to the method were 17 software developers in 2001 gathered to discuss lightweight development methods. The result was a published manifest that described the agile methodology and its values (Fowler & Highsmith, 2001):

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

In an organized dynamic process, where the project producer is in close contact with the users, detailed descriptions and documentations will not be needed on the same level. Elements in the agile methodology are typical multi iterations, and these will repeat every 2-4 weeks, with a new version to testing. These elements can be daily stand-up meetings, test driven development, sprint planning etc.

Figure 2: Development methodology

7

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

This project is based on the agile methodology where test personas are involved, used for testing of the prototypes established in this project.

As a practical-technological approach for increasing our knowledge regarding our future development platform, we also use the agile methodology to do initial tests on respectively open source and ESRI development platforms necessary to solve one of our use cases. Our goal for this task is to test how easy or difficult it is to set up a technical environment adequate to solving this task. The prototypes of system development are presented in Chapter 5 together, while the technology survey in Chapter 4 is used to pinpoint which technical issues are most critical in our development of a full functioning technical prototype.

We have only 3 weeks to reach a basic knowledge of open source and ESRI in order to develop prototypes, and in this period we used Figure 2 as our development methodology. This was done by estimating all the fundamental requirements for Use Case 1, and afterwards listing them after priority. After this we take them module by module and developed, until all modules were complete, and afterwards uploaded the product for the system release.

2.2 Geodesign methodology The main object of this project is to check and reduce the main risks of our Mobile PPGIS Project. A basic geodesign model is made to make perfect map communication, and insure all thoughts and needs have been brought to live. But in our project we use it to make a better understanding of the development requirements and interaction to reach a prototype in open-source and ESRI environment. In the process from Value to Product, will the basic geodesign model visualize as a simple roadmap for the readers, and it will as well bring the basic and sharp information in front.

The basic geodesign model works when a producer creates information design to a user, in our case, NCA. According to Brodersen (2008), information design contains 5 fundamental elements: Value, Content, System, Interaction and Product. These 5 elements together will bring a better visualization and increase the project for a given user. The process starts with a Value the user want to achieve, and in order to complete that the Content will describe what it has to contain. When the Content is made, it will be possible to analyse what the System shall contain to make the Content work, and through the Content the user have the Interaction with the Product.

Figure 3: Geodesign model

8

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

As illustrated in Figure 3, we use the five boxes with a definition that adapts to our specific project, in Chapter 5 we will further discuss system, content and interaction, because these are widely used and need more information than a figure can contain. In our project, the five fundamental elements can be described as below:

- Value refers to the objectives of our project. By executing the project, we shall achieve both short term and long term goals. When the transformation processes are successfully done, Value of our system design can be evaluated based on those success statements.

- Content is everything the user will be able to see on the client site. This includes all styling and design up-set, with frames, logo, themes, colours and contrast. We choose to select the most important elements for the project, instead of focusing on the very details like why it is <h1> instead of <h2> in a given HTML (Hypertext Marckup Language) headline text.

- System is what makes the application to do exactly what we want it to do. By this we mean the codes, platforms and libraries to make the motor run, and scripts that are important in the application, to fulfil the prototype requirements Chapter 5.1. In the geodesign model it will be presented as the names of the coding languages and libraries, and a further description as text for each prototype.

- Interaction is like a user manual for the right way to interact with the product. This is in the simplest way described in the geodesign model, and afterwards compared with Use Case 1. Interaction can also be visualized in a flow model.

- Product refers to the prototype in this project. Users can use Product to realize their requirements.

2.3 Personas and Use Case methodology The project development is responding to the personas feedback and the evaluation of Use Case 1. The personas have a very important role in this project, and the basic theory is therefore introduced here.

2.3.1 Personas method

Personas are a tool to bring artificial users with a high degree of personality into the system design process to test user experience. Personas bring down the cost of involving real people into system development. A systematic analysis of user groups for a given system can in this way give a very effective involvement of the users, and hopefully gives the same results as involving a large number of real persons in development of a given tool, in this case a PPGIS (Benyon, 2010).

Personas was first introduced by Alan Cooper in his book The Inmates Are Running the Asylum (Cooper, 1999). The goal is to bring your users to life by developing personas with real names, personalities, motivations, and often even a photo (www.agilemodeling.com, 05-04-2013). Personas should include users both within NCA, and the citizens. In NCA’s oil spill emergency response organisation, the most relevant group for a PPGIS is the Operation-unit. They are probably the main group to verify the GIS-based information, during operation. One personas to represent the Operation-unit is therefore set up to represent users within NCA.

9

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

2.3.2 Use case modelling

Scenario based system design (Benyon, 2010) can be based on single or multiple user stories representing the scenarios, or the scenarios can be more specified and set into formalized design resulting in use cases.

Use case modelling is a systematic and analytic way to specify user requirements of a system (Benyon, 2010). The process needed to get to good use cases should starts by bringing all the important practical situations which include requirements that should be handled by the system. A scenario-based process brings the given situations into more general scenarios, which then can be structured into given use cases. The process of structuring should take into account the general structure of the system to be build, in our case a smartphone GI system, to facilitate a good design process. The development of use cases should also focus on the human – machine interaction, to make the structure of the system user friendly and intuitive.

Use cases have been criticized for not being an agile method, because being a less flexible and time-consuming task than just writing user stories3. However use cases are also frequently used in agile system development probably because of a general popularity, and might also for the more systematic approach (www.breathingtech.com, 06-04-2013).

In system development many different templates have been used for collecting use cases, e.g. Sæther and Levys examples (www.breathingtech.com, 06-04-2013, and www.gatherspace.com, 03-04-2013).

2.4 Flow model methodology In IT-communication it can be very useful to document, design, analyse or managing a product by showing it in a designed model. Models/diagrams communicate to a different type of decision makers, which often have a higher technical perspective. A model can give a fast picture of who complicated a product is, and it helps the viewer to understand the process and structure. The first flowchart looking model was developed already in the early 1900’s by Frank Gilbreth (Graham, 2004). For many different reasons the use of process modelling increased, and they provided a base to plan, manage, and execute projects. The demand for process models came from requirements defined by standards like ISO (International Standards Organisation), or internal policies within an organisation (Browning, Fricke and Negele, 2006).

To create this projects flow models five different boxes and connectors are used to visualize the process models (Figure 4).

3 A typical user story can be structured like this: As ____ (role)I want ____ (action) so that ____ (goal)

10

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The start and end boxes visualizes where the application starts and ends. End boxes includes where the application close and another system part opens.

The diamond box shows that the users have an opportunity to take a decision.

The Rectangle represent an event which is controlled within a process, this comes by a step or an action that is taken by a user decision.

The box represents data in- or output, and is used in situations where the user can add data to the application database. The connectors will tell if the data have to be there or if it is optional.

The box is used in case of alternative process, and it can be skipped if it isn’t needed.

This purple square signals there is a part after this box, but it is not a part of the use case.

Figure 4: The six different boxes used to visualize the process models

11

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

12

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

3 User requirements The management of user requirements are often the most critical part of system development, and chapter 3 will present a way to assure requirements can be well handled. The found requirements on information exchange in oil spill episodes are first represented. Then we present NCA’s organisation chart for oil clean-up operation and the relevant procedures on information exchange, before summing up the user requirements in use cases. We then personalize the personas - the fictitious test users - to confront the stepwise results of a possible system development. After a presentation of main issues on smartphone as a user interface for PPGIS we develop a Mock-up for use case 1. This chapter then ends up confronting the personas with the Mock-up, giving an example of how an iterative development strategy can be used to develop step by step.

3.1 Requirements of information exchange A general requirement of information exchange between oil spill actors and citizens have been documented in our previous survey (Verup et al., 2013). The variation in stakeholder interest is further discussed in chapter 3.5, based on variation in the stakeholder variables power, legitimacy and urgency (Mitchell, Agle & Wood, 1997).

As the previous survey only presented results of interviews of oil spill actors - NCA, IUA’s (Interkommunale Utvalg for Akutt beredskap) and Søværnets Operative Kommando - we have performed interviews with two citizens to get the full picture including information requirements among citizens. Two citizens representing major stakeholders and being familiar with oil spill situations were chosen. We followed the same method as used on oil spill actors in our previous survey (Verup et al., 2013), however focusing on requirements on information exchange based on their experiences from real oil spill clean-up operations (Server in 2007, Full City in 2009, and Godafoss in 2011). The results of the interviews are given in Appendix 1, which improved our knowledge, especially concerning which information that is relevant for exchange.

A two way communication is preferred if possible. Telephone or other two-ways communication facilitates guidance from NCA on what information is of value in the present situation.

3.1.1 Information requested by citizens

Especially HSEQ (Health, Safety, Environment and Quality) information to affected citizens is prioritized on the agenda, as getting exposed to oil spills can cause major health effects. The citizens mainly require information on the oil spill situation and on the prognoses:

- HSEQ information, including guidance on how to act on the spill and possible risk, which pollutants

and toxins are present in the oil?

- What is the situation? Is the media giving a right picture?

- Where is the oil spill site and where is the oil?

- What are NCA and others doing with the oil spill? Where have oil spill recovery started?

- What are the prognoses of the spread of the oil?

13

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

- How can I clean up my private oil infected quay and vessel?

- Which areas are given restrictions on fishing or dietary advices caused by the oil spill? Should bathing and other shore based activity be avoided?

- What is the final result of the oil spill after clean up?

3.1.2 Information requested by NCA

NCA have stated that oil spill reports from citizens will be of value for the acute oil spill operation, reports concern both sea and shore. The most relevant information is:

- Oil spill reports including pictures, telling where oil spill is observed and type and quality of oil. - Reports on oil spilled birds and sea mammals, and other marine or coastal livings

- Local weather conditions can be of interest, mainly temperature of air and sea, and direction and

speed of wind and stream

- Knowledge on local oil spill recovery resources, private oil booms etc.

To prepare for development of a Smartphone PPGIS oil spill information exchange we should also look into NCA’s Information procedures.

3.2 NCA’s Information procedures How can a smartphone PPGIS be included as part of NCA’s information strategy? Verup et. al. (2013) presented a need for including more documentation on procedures and routines in NCA’s oil spill operations, and finding organisational challenges.

In this study we refer to large oil spill situations, meaning situations taken over by the national authority (NCA) because of high potential of environmental damages and need of a considerable response, best handled on a national level. The organisation of the acute oil spill operation is shown in Figure 5. The need for information exchange with the public can be huge during operation. All the different units in the operation are involved in information exchange, but the Information staff is the major contact out to the public.

NCA’s contingency plan (NCA, 2013) refers to “steadily rising expectations for communication and dialogue with the public during emergencies. Internet and social media, the number of channels of communication out has increased significantly. The new media society requires custom information and indeed this has been shown to be important during critical events”

The three units, The Information staff, the Operation unit and the Planning and Environment unit, shall settle a number of functions relevant for information to and from the public (see Appendix 2). These functions are defined in the different procedures, instructions, specifications, and check lists in NCA’s contingency plan.

14

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 5: NCA’s organisation chart for acute oil spill operations. The Central organisation is set within the grey box consisting of the leader, three units: Operation, Planning and Environment and Logistics, and then three boxes giving the leader’s staff. As an operation also can interfere with operations saving life and health it is important to have a good contact with the Rescue coordination centres. Under operation there can be several on scene commanders with their own organisation, following the same structure as is shown for the main Action Leader. In this way everybody can easily understand their position as part of the overall organisation. The organisation chart represents a CIS (Incident Command system), keeping the same organisation in ‘peace and war’, avoiding troublesome re-organising when large oil spill actions have to establish quickly

3.2.1 Oil spill reports

For oil spill reports by mail or by telephone into the operation, the Operation unit is the first point of contact, given in the function overview in Appendix 2. The contingency plan refer to the function as ”Must respond to and redistribute all external requests coming in to action management via the main phone number and the action mailbox”. This implies that reports on oil spill both should be responded to, and distributed further into the organisation from here. The Operation unit should have an overview of all the operations under performance and stay updated on the situation.

The Planning and Environment unit shall:”Collect, compile and systematize information from other staff functions”, and are also responsible for estimates of the possible environmental threat in the situation.

The list and map of reported oil spills hence is updated mainly by the Operation unit, but the Planning and Environment unit could be assisting in this because of GIS-skills are most available there. The need of verification for oil spill reports was discussed with two members of the Planning and Environment unit, S. Berger, and K. Aasebø 28-05-2013. A number of verification statuses were given, without being definite on which unit to perform the handling and verification of such oil spill reports.

15

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The possible verification statuses found:

- Unchecked - Received and read. - A Given priority on each report, according to environmental values and other values threatened at

site. - Eventually set starred pictures where many oil reports are received, pointing out the most

important pictures. - Sent further to responsible actor to verify on site, either by NCA or by IUA - Verified on site

In this citizen reporting phase, oil spill reports are today received in the Operation unit, eventually getting assistance from the Planning and Environment unit. Further handling of reports will vary.

3.2.2 Oil spill situation and prognoses

The public also show high interest in the oil spill situation and prognoses. Both the Operation unit and the Planning an Emergency unit should be updated on these issues, and have responsibility for different parts.

The Operation unit ensure to update the location of all operating units at site. They also produce the drafts of “action plans” and “action managers’ orders” bringing the updates on oil spill situation. The oil spill situation is kept updated in the Planning and Environment unit, which also runs analyses to make prognoses on the oil weathering, and spreading caused by wind and stream.

The Information Staff are responsible for information out to the public. Based on internal situation reports and updated oil spill situation, eventually including prognoses. They write updated public situation reports, published on NCA’s acute website, eventually on social media like Facebook and twitter

Pictures are also gathered from NCA’s surveillance plane and other operational units, plus external participants like the coast guard, which are included in information to the public.

In this orientation phase, the information out to public today is mainly handled by the Information staff, but citizens will also get information from operational teams out cleaning up the oil and other participants.

The Smartphone PPGIS for oil spill information exchange interfere with functions set in both the Operation unit, the Planning and emergency unit, and the Information staff. A model of information flow is made to visualize this in chapter 3.4 after defining the requirements in use cases now in the next chapter.

3.3 Use case modelling As this study is based on a survey of user requirements and much effort have been used to collect the user requirements, it is worth the time needed to structure this into a formalized design as use cases. The extensive overview of user requirements give a chance to formalize good use cases, and good use cases are a good basis for the system development. The effect and consequences of any changes of functionalities or design In the process of system development will then also be seen immediately by referring to the use cases.

Based on the user requirements given ahead in chapter 3.1 and 3.2, we have designed seven use cases (Appendix 3) to represent the user requirements of the Smartphone PPGIS.

16

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

We have first established a template for use cases (see Table 1). The template design supports an agile process for development, designed after guidance by Darren Levy’s 13 killer tips to create effective use cases (www.gatherspace.com, 03-04-2013). Our template should support effective use cases, not to include more information than necessary. Further details will then be stated if required during application development.

Table 1: The use case template for the Smartphone PPGIS for oil spill information exchange, exemplified with Use Case 1

USE CASE 1 Report oil spill with photo plus georeference

Goal For the citizen to send pictures of oil spill including geolocation to NCA

Summary An Oil spill report is sent from a smartphone to NCA’s database, including photo, georeference, text and report category

Actor Citizen

Pre condition A citizen has observed oil spill The application is used on the smartphone on site

Successful Post condition

Oil spill report sent, with confirmation back to the user

Basic course of events

1) The user takes up his smartphone, and starts the PPGIS application 2) The user takes a photo 3) The user adds a note to the picture 4) The user chooses category of report (1 = oil spill observed at site, 2 = oil spilled birds or sea mammals observed) 5) The user enter contact details 6) The user sends the oil spill report.

Alternative paths

Report can be given by calling or sending an e-mail. The report must then be manually registered by NCA representative.

Priority, possible profit

PRI 1

Author and date

John Morten, 17.3.2013

Our use case template includes 10 elements exemplified with the use case 1 “Report oil spill with photo plus georeference”. “ID and title” is main reference for the use case. The “goal” for each use case is included to be aware of the specific goal for each use case, to help focus during development. The “summary” should be the short version of the “basic course of events”. “Actor” tells who is to use the system. “Precondition” and “successful post condition” show in which situation the application is to be used and tells the wanted result. “Alternative paths” should refer to other possible use cases or other ways to achieve the successful post condition. “Priority, possible profit” gives the relative ranking between the use cases and presents the possible value of the successful post condition. Finally “Author and date”, helps to find the source of the use case, good to know for further discussion.

Use case 1 has been used as the basis for a test on technology performance presented in chapter 5, The seven use cases altogether should be the basis for a further development.

17

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

3.4 Data modelling Modelling is the central activity of software design and deployment, because models assist communication, visualization, control and risk management. In order to describe the data relationships, dependencies and usages, three different models - database structure, workflow and information flow - are discussed in this chapter according to requirements from users and NCA organisations.

The Unified Modelling Language (UML) is widely used in software modelling. The major characteristic of UML is methodology independent – Regardless of the methodology that is applied to perform analysis and design, UML can be used to express the results.

Figure 6: UML 2.5 diagrams overview (www.uml-diagrams.org, 28-04-2013)

UML is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive system (Booch, Rumbaugh and Jacobson, 2005). UML was officially released in 1997 and is now claimed as OMG4’s most-used specification. The

4 OMG: Object Management Group is an international, open membership, not-for-profit computer industry standards consortium, founded in 1989.

18

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

latest version of UML, 2.5, defines sixteen diagrams divided into two major categories (Figure 6). A structure diagram shows static structure of a system and its parts on different abstraction and implementation levels, and how parts are related to each other. Structure diagrams are not utilizing time related concepts, while behaviour diagrams show the dynamic behaviour of the objects in a system, which can be described as a series of changes to the system over time (www.uml-diagrams.org, 28-04-2013).

Our project can in principle be described in different UML diagrams, for example the software design process, or interactions between user and designer and so on. To get a good idea of complexity and content of the database infrastructure with relations and connections parameters we have made a detailed UML class diagram as a data model for a Smartphone PPGIS based on the seven given use cases. A detailed data structure model is setup in UML class diagram and can be found in Appendix 4. The class diagram describes a static structure by showing the system classes, their attributes, operations and relationships between them. The model includes ”client side classes” which should be located on the smartphone, “server side classes” which should be located server side, and “common classes” with common objects. Cardinality, dependency, generation and aggregation are defined between classes located client side and server side. Boundaries, constrains and operations are defined for the classes. This model present the complexity of a system that could support all the seven use cases given, however adaptations should be made according to structures given by the relevant GIS technology used.

Figure 7: Work flow model for Use Case 1

19

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

A work flow model (

Figure 8) is produced based on use case 1 showing the process to result in oil spill reports sent to NCA. This model is used to produce a Mock-up presented in chapter 3.7 and further in the development of a technical prototype presented in chapter 5. An information Flow model, given in Figure 7, shows the suggested flow of information between citizens and NCA’s oil spill organisation, based on the user requirements found, and the review on procedures and instructions in NCA’s contingency plan (chapter 3.2).

Further modelling, including models on system structure and models on system behaviour, should later be performed during development when a clarification of application requirements is needed.

Oil spill reports

Verified oil spill reports

On-Scene Commanders

Verification(NCA, Operation Unit)

Oil spill situation

Oil spill reports

Oil spill situation

Citizens

Figure 8: Information Flow Model. The Operational unit in NCA’s oil spill response organisation is suggested as the main responsible unit for receiving, verifying, and giving response on oil spill reports. The verification is however to a large degree based on site investigation and comments from On-Scene Commanders and their personnel

3.5 Personas To involve fictitious users in development of our application we establish a given number of personas which we repeatedly will use for tests during the development.

We have analysed the expected users of our Smartphone PPGIS in our previous report no. 1 (Verup et al. 2013). Six categories of affected citizens were set up; however any citizen could also represent more than

20

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

one of the categories. Our design of personas should represent the variation among citizens, to prepare the application well for the real life, with a limited time and resources for testing available.

Choice of personas is also performed to represent the variation in stakeholder type, by giving them variation in the three main variables of stakeholders presented by Mitchell, Agle & Wood (1997); power, legitimacy, and urgency - on the issue of oil spill emergency response. By selecting different levels of power, legitimacy and urgency we maximize the variation in expected responses during testing.

Table 2 Categories and stakeholder typology presented by the three citizen personas

Personas

Categories of stakeholders defined in our report no. 1:

Espen Benny Laila

People who often reside by the coast or at sea

X X

People who live near sea, or have holiday residence near sea

X

Environmentally engaged people X X

People with high interest in hunting and fishing

X X

People with high interest in birds, and ornithology

X

People running a coastal business, easily affected by oil pollution at sea (coastal tourism, fishermen, fish farmers, or other coastal business)

X X

Stakeholder typology

The stakeholder variables P – power, L – legitimacy and U – urgency, according to Mitchell, Agle & Wood (1997).

Definitive stakeholder (PLU)

Expectant stakeholder (L, U)

Latent stakeholder (U)

Smartphone knowhow High Low, but knowledge on cameras

Medium

All citizens should use the smartphone to send in oil spill reports. Even though a majority of Norwegian today have a smartphone the experience with it will differ very much, and limited experience is obviously a challenge when we want all of them to use our application. The personas have therefore been chosen to

21

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

have different levels of experience with their smartphone. Altogether the variation brought in by the personas is presented in Table 2, and the realization of them is presented in detail in chapter 3.5.1.

The number of personas should be kept low, because too much effort will be needed to get to know a large number of fictitious users and responses from the personas will start to repeat, hence the number of 3 personas representing the citizens, and one to represent NCA is chosen as practice in this study.

Kari is chosen as the personas to represent NCA. She is a part of the unit Operation within NCA’s operational organisation (see Figure 5). This unit is today receiving oil spill information from citizens, and is expected to be responsible for the needed verification process we have set up in the use cases.

3.5.1 Four personas

Espen

Married, and three children

Main activities: Camping life and fishing

After many years of long working days and small children hanging on his legs, Espen (38) has finally made his Camping business by Havstranden Camping a well running business, with 20 persons on full time during the tourist season from April to October. Wintertime he loves going out with his brand new leisure fishing boat, inviting friends, or bringing his two sons (13, and 14) and one daughter (10) for day trips. Sometimes he also goes for a weekend trip, fishing on the banks west of Denmark.

Espen started as a carpenter, he is handy, and solve most of the practical issues on the camping himself, with assistance from his crew during season. He knows the fjords and Islands in the area like his own pickpockets, and has good contact with local fishermen, and holiday residents.

Benny

Single nature photographer

Hobbies: Birds, nature and reindeers

Benny (67), the famous bird man in Nordvik in Finnmark, grew up in Bergen, but quickly became a “nature man”, bringing his tent and sleeping bag with him to the fjords, the heathers or the mountains for nature activity, in any weather, and through all the year. After a standard 9 years of school he was picked up as teacher for Bergenfjord folkehøyskole, teaching nature knowledge and sports to the pupils. Benny got tired after 15 years of giving spoiled youngsters a “lesson for life” during their year at Bergenfjord folkehøyskole. Being single, he packed up his things and got a job at Nordvik municipality, as nature manager (50%). Adding to the salary, he does some “nature photography” for magazines, and helps with reindeers during

22

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

summer, when reindeers go to Nordvikvidda. Benny, with a small beard and a rough outlook, has a good eye to a few of the local women, but is still single and without parent responsibilities.

WWF Laila

Single and enthusiastic

Hobbies: WWF, travel

Crazy enthusiastic, and in everything she does, she does it fully and completely. Laila (18) has recently been in Italy with her parents taking a look at the cruise ship “Costa Concordia” lying northwest of Rome after the grounding Friday 13th Jan 2012. She has because of this, two months ago joined the local WWF, and plan to take the bird washing course they have established after the ship accidents in Norway the last years. Laila wants to become a nurse, but has to redo some exams to get into the study in Nursetown, 100 km west of her hometown. She is planning to stay with her favourite aunt (single and saint) during studies. Laila is blond, and like fashion and chatting, and have been active in AUF, Natur og Ungdom, and the local gospel choir. Laila loves to sing.

Kari (NCA)

In a relationship Main activities: Amphibians, skiing and travelling

Kari is 25. She has been member of “Natur og Ungdom” until recently. She is especially aware of environmental political issues locally and very engaged in biodiversity, and local threatened amphibians. She prefers public transport if possible. After taken a master in Nature Management at Ås University (“Distribution of amphibians in South-Western Norway”), she’s had some short jobs for the local municipality before joining the operation unit in NCA. She has skiing and travelling as main interests.

Kari have dark curls, and love hiking in the mountain with her girlfriends, and her newly added boyfriend.

23

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

3.6 User Interface on a smartphone Smartphone is found as the preferred communication tool for oil spill information exchange with citizens. Smartphones are a very different platform for communication than the more traditional desktop or laptop displays. The most obvious difference is the difference in size of displays, but many other issues have to be handled to make a good user interface to give an intuitive interface for any citizen. The user interface should also be adapted to today’s designs of smartphone applications giving a modern and welcoming image as well as having its own style.

Smartphones have grown in size the last couple of years, but should in general be sized to fit in a pocket. Modern smartphones generally vary in size from approximately 2.8 inches (screen diagonal, e.g. Samsung Galaxy Pocket) to 5 inches used on Samsung Galaxy S4. The latest iPhone models with 3.5 and 4 inches display (smartphones.findthebest.com, 03-05-2013).

Too many details on these small displays will easily clutter the user interface, however all needed information should be included. The user interface must also consider that many smartphones changes between landscape and portrait view based on internal gyro meter.

The use of a smartphone interface is most frequently a touch based screen handled with the users fingers, some smartphones using keyboard or pen as well. Multi-touch is often supported, e.g. enabling use of two fingers to zoom in or out on a map.

The fingers lack the same level of precision as the mouse on a PC. Wang and Ren (2009) have concluded on minimum size on targets for multi-touch interfaces as 5.8 mm radius for circular targets, and 11.5 mm per side for square targets, which also imply that a limited number of targets should be included on any panel on the interface. The placement of targets should also be based on how the smartphone is placed in the hand to make an ergonomic good design

Smartphones are used in all kind of environment, outdoor, indoor, winter time and summer time. This makes challenges to how the design of smartphone apps must be, to become user friendly. Numb fingers are slow and less precise. Clear sunlight can decrease the visibility of the smartphone display and especially blur the different shades of colours.

Impatience is a very common issue for applications on smartphones as well as computers and slow performance can be very critical for an application. Both installation and use should go smoothly with as little delay as possible.

Gomez (2011) study of user habits says

“Nearly 60% of web users say they expect a website to load on their mobile phones in 3 seconds or less and 74% are willing to wait 5 seconds or less for a single web page to load before leaving the site. 50% are only willing to wait 5 seconds or less for an application to load before exiting the site”.

The report also saying 71% of users in 2011 expect a mobile app to respond with same speed or quicker on mobile units compared to websites on a computer or a laptop.

For the suggested Smartphone PPGIS for oil spill information exchange, we expect a high motivation among most affected citizens to contribute with oil spill reports, which can give an extra patience among users of a

24

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

suboptimal user interface. On the contrary, to be an application for all citizens - young and old, rich and poor - the application should be very intuitive and user friendly.

3.7 Response on Mock-up Prototype To quickly and efficiently get response on how a Smartphone PPGIS application should be, we have set up a Mock-up. A Mock-up has some strong sides which support the development of technical equipment. Generally, a Mock-up is an un-scaled replica design to clarify, simplify and illustrate an object. It is in generally constructed to show the essential functions and parts of an object (Dallmann-Jones and the Black River Group, 1994).

The Mock-up was made in this study, where all four of us brought up our ideas on how the first sketch Mock-up should look like. The sketches were made on a couple of blank papers containing a blank iPhone frame. The four sketches were presented and evaluated. The product of this, combining the best ideas, where brought into one Mock-up, and then designed in Photoshop for presentation for the personas (Figure 9).

Figure 9: A temporary Mock-up

By involving the personas this early in the process, we both get experience with the personas method and should get good inputs from three different fictitious citizens, plus one personas representing NCA. The point is to let the personas come with their ideas and wishes, as early in the development process as possible. We put the glasses of the personas on, put ourselves in their place and looked constructive on the Mock-up reflecting their interests and needs. As guidelines for the personas, some bullet points were made for the testing of the Mock-up, to force the personas to evaluate on the same criteria.

Evaluation bullet points:

1. Design comments. 2. Workflow intension. 3. Other things we should think of?

25

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The result from testing the Mock-up for use case one on personas worked very well, with ourselves participating as the different personas very energetically. They were asked to write with one line the best feedback to each of the bullet points. The most important feedback comments for further development were:

• Kari: 1. “Not really much design over this, I don’t think of NCA at any time.” 2. “Easy and lined process.” 3. “No.”

• Espen: 1. “I think it’s good, it looks like anything else on my Iphone.” 2. “It’s the smallest app, I have ever seen. That’s good.” 3. “Add a logo or something like that.”

• Benny: 1. “Since it’s a Mock-up, I’m sure you guys have thought of putting something more into this

design.” 2. “Well, I don’t know if this can work in web-applications, but the process isn’t hard for any

citizen. 3. “The most important for me is that an application has to give me something in return, else

it doesn’t make sense to have it. So you have to add some entertainment, or interesting. When that’s said, then even an old man has a chance here.”

• Laila: 1. “It had what was necessary.” 2. “I would like to be more specific in the details.” 3. “I think it’s a good idea and I’m sure many environmental activists would be able to commit

to this application.”

These responses will be considered and brought into the development of a lightweight technical prototype later in chapter 5.

We have now in chapter 3 presented the user requirements of a Smartphone PPGIS for oil spill information exchange. To assure user requirements can be handled well we have defined seven use cases to give a good structure, suggested four personas as test persons during development, designed the most relevant models for system development, and set up a mock-up showing the user interface and data flow.

We will now change over to the technological issues of a Smartphone PPGIS in chapter 4.

26

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

4 GI technology for smartphones In Chapter 3 we have discussed the needs and requirements from both citizens and NCA. In this chapter we will concentrate on the modern technologies to determine whether or to what extent our ideas can be realized in practice. Similar applications with purpose of public participation or response to emergencies are reviewed in order to illustrate the technical possibilities as well as challenges.

Our ultimate goal is to promote mobile PPGIS for oil spill information exchange. To establish a full mobile PPGIS we choose server-client architecture with GIS integration. The server side provides web and mapping services, so that the client side (smartphone) can communicate and exchange information with server. Technical components of each side are discussed based on their functionalities and limitations.

4.1 Server technology This chapter focuses on the server side of application development. The relevant server technologies are discussed with emphasis on GIS features. Purpose of this discussion is to reveal the suitable server system architecture to our application.

4.1.1 Web server

A web server is a server responding to http (Hypertext Transfer Protocol) requests through the worldwide web or on a local network. The web server is often setup to include services running on the server, or further request other servers to do necessary calculations to be able to serve the requests in the web-GIS. The web server is the basis for Web GIS, because it serves http calls from smartphone units. Examples of standard GIS requests as WMS, WFS will be further presented in chapter 4.2.1.

Figure 10: Main architecture of a web-server

27

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

As for an oil spill information exchange PPGIS, a web server should be able to give map views, and views of attributes to the most relevant feature classes, plus editing of spatial features connected to the oil spill reports to be given (Figure 10).

Apache http server, Internet Information Server (IIS) and Nginx are the three most popular web servers (news.netcraft.com, 25-05-2013). IIS is a standard part of the MS Windows Server Software, but are now also included in some of the Desktop Windows software, and can be activated as a service on a desktop Windows 7. IIS works only on windows platform and supports fully .NET. The Apache http server can easily be installed on any OS. The Nginx can also be installed on most of the OS, but are less popular than Apache, as far as number of downloads from CNET5 is concerned.

Statistics from Netcraft (Table 3) refers to Apache http server as the market leader used on 51% of the web sites globally by April 2013. Microsoft IIS as the closest competitor have 20% of the market counted by sites. Nginx have 15% of the market share with Amazon as the most known example. For the top 1 million web sites in May Apache have 53% of the share, Microsoft 17%, and Nginx 15%.

Table 3: Updated statistics of http servers, show Apache http server have a clear majority (51%) of the web servers worldwide, (news.netcraft.com, 25-05-2013)

Developer April 2013 Percent May 2013 Percent Change Apache 331,112,893 51.01% 359,441,468 53.42% 2.41

Microsoft 129,516,421 19.95% 112,303,412 16.69% -3.26

Nginx 96,115,847 14.81% 104,411,087 15.52% 0.71

Google 22,707,568 3.50% 23,029,260 3.42% -0.08

According to Jackie Ng (osgeo-org.1560.x6.nabble.com, 03-05-2013) the choice of web server platform is very much related to the GIS connection capabilities and the language we come to use for server communication: “Your choice of web server generally boils down to what web development platforms you will be integrating your MapGuide application with. Java or PHP6? Choose Apache. PHP or .net? Choose IIS . PHP or don’t care (you just want to show maps)? Choose Apache.”

In our opinion, the choice of web server shall not bring any risk or obstacle for the services that are already presented in NCA. If there are existing http servers, databases or GI-systems that our server should tightly connect to, the independencies of these systems should be dominating when we choose the web server platform. Another important aspect is personnel’s qualification and knowledge level to the web server. As our application aims at more people will be motivated and engaged, popularity of the web server shall also be taken into account seriously.

During the review of web server packages, we have noticed that Apache brings up many possible wrap-ups including other extensions for the web-server. For example there are three regular packages that are related to Apache:

5 www.cnet.com. An American tech media website that publishes reviews, news, articles, blogs, and podcasts on technology and consumer electronics globally 6 PHP: Hypertext Preprocessor, a server-side scripting language designed for web development.

28

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

- EasyPHP. Apache http server, MySQL, PHP/phpMyAdmin, Xdebug + modules WordPress, Spip, Prestashop, Drupal, Joomla!, and more (www.easyphp.org, 03-05-2013).

- XAMPP. Apache http server, MySQL, and PHP + Perl + Filezilla Server + Tomcat (xampp.en.softonic.com,03-05- 2013)

- WAMP-server: For Windows OS, installing Apache http server, PHP/phpMyAdmin and MySQL. (www.wampserver.com, 03-05-2013). WAMP have, as shown previous here, had the highest download rate recently.

Besides, there are several http server extensions available for Apache. For example, Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" http web server environment for Java code to run (tomcat.apache.org, 03-05-2013). These packages and extensions enhance Apache’s functionalities and improve its compatibilities with different operative system, server side scripting languages and database platforms, eventually spatial databases. As we are beginners on this field, we choose XAMPP as an easy-to-use and well-documented package to start with (Chapter 5).

4.1.2 Web Map server

Web map servers extend the interoperability of GIS systems utilizing the web. These services require client software sending requests and server software responding correspondingly. The server and the client can be installed at same site/computer, or at different sites requesting services over the web by the standard web protocols TCP/IP and http. Geo-information is hence available worldwide on the web, or can be kept in separated intranets (Figure 11).

Web map service standards

Other than the traditional download methods, OGC7 have launched a number of standards for geoservices. We list up the most relevant standards for developing an oil spill information exchange PPGIS, referring to Fu & Sun (2011) and OGC (www.opengeospatial.org, 29-04-2013):

WMS (Web Map Service) is an ISO-standard for requesting and serving maps on the web, generally rendered as picture-files in specified format, e.g. jpg, gif, png. The services are set up to deliver maps on specified datums, combining sets of feature classes and raster layers into a single picture. This gives rise to all kind of combinations of spatial data, where WMS-layers can be overlaying each other with given opacity, and bringing WMS-services from different sources on the web together. WMS are extensively used worldwide, however WMS does not bring attributes information on the features on the map, and symbolisation are set from the provider of the service. In order to improve this, OGC specified SLD (Styled Layer Descriptor), so that users themselves can render or symbolise a layer. This is relevant in the context of many existing services that are exhibited. If we shall provide our users with many different base map, WMS service is a good choice.

WMTS (Web Map Tile Service) is a given standard for implementation of WMS-solutions to serve digital maps using predefined image tiles. The services advertises service metadata documenting the given tiles available in each layer, including e.g. type of content, format, available coordinate reference system at each

7 OGC: Open Geospatial Consortium, founded in 1994

29

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

scale. WMTS is especially relevant in this project because Tiled services are usually not heavy sized and require less bandwidth of the internet connection.

Figure 11: products delivered from web map server to client (Benedict, 2005)

WFS (Web Feature Service Interface standard), as an OGC standard, defines an interface for specifying requests for retrieving geographic features across the Web using platform-independent calls OGC (www.opengeospatial.org, 03-05-2013). WFS defines interfaces and operations for data access and manipulation on data. GML (Geography Markup Language) is the specified feature encoding for input and output, but other encodings may also be used. The basic WFS allows to query and retrieve features, while a WFS-T (Transactional Web Feature Service) allows to create, delete, and update features. These editing capabilities and features are especially interesting in designing mobile sites. If the reported data shall be available again with relevant attributes, WFS is the obvious choice.

KML (Keyhole Markup Language) was acquired by Google 2004, created by Keyhole Inc., and Google handed it freely over to OGC for increased utilization. KML was published as an OGC standard in 2008. KML is an XML-based (Extensible Markup Language) file format which specifies a set of features (place marks, images, polygons, 3D models, textual descriptions, etc.) for display in geospatial software. Format also

30

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

include, such as tilt, heading, altitude, hence include INS8-data. KML files are very often distributed in KMZ (Keyhole Markup language Zipped) files, which together with georeference can include any overlays, images, icons, and 3D models. KML is widely supported by many web map servers. As for this project, the most interesting point is the seamless connection between KML and Google Earth.

In the recent years, there are upcoming several new standards, such as WCS (Web Coverage Service), WPS (Web Processing Service) and GeoRSS (Geographical Really Simple Syndication). But they are not discussed in depth her, as they are not used in this project.

Table 4: Norwegian web map services available as of 2012 (Norge digital, 2013)

Service type of available resources 2011 2012

WMS 127 145

WFS 6 10

WCS 1 1

WS (web services) 7 8

Downloadable dataset 100 239

WPS 1 1

Applications 66 76

Norway Digital’s Yearly report of 2012 (Norge digitalt, 2013) has presented a statistic of the type and number of above mentioned services. WMS is the most popular service type that is available within the spatial data field, after the traditional download method (Table 4). Considering the compatibility with most of the existing services and platforms, WMS shall weight highly in our choice of providing web map service.

During the literature studies, we have also found several web map services that are related to oil spill information exchange in Norway (Table 5). It will be interesting to see how many services can be integrated into our application, so that other environmental groups can also benefit from our application.

Table 5: Some relevant web sources for spatial data for oil spill information exchange (www.miljokommune.no, 03-05-2013)

Relevant datasets Services Owner

Place names, Basic chart features http://www.statkart.no/Kart/Kartverksted/Kartverket-pa-nett/

Norwegian Mapping Authority

Nature resources and Areas of priority

Naturbase (http://geocortex.dirnat.no/) + wms services

Norwegian Directorate for Nature Management

Data on fisheries, and fish farming http://kart.fiskeridir.no Norwegian Directorate of Fisheries

Resources for oil spill response and other relevant data, including a lot of MetOcean data

Kystinfo: http://kart.kystverket.no/ + wms services

Norwegian Coastal Administration

8 INS - Inertial navigation system are computer based systems which calculate movement by data from motion sensors.

31

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Web Map Server software

There are many Web map server software to choose from. A primary distinction is made between open source and commercial software. Developers of systems have mainly been following one or the other way. The commercial software used in NCA is ESRI’s ArcGIS Server; however others, such as Quadri Map Server, also have a lot of the Norwegian municipalities as customers. On the open source side, we have been introduced to GeoServer in our MTM-study, and Mapserver is a part of NCAs web map solution Kystinfo. The open source market includes also other solutions like MapGuide, Mapbender, and MapFish (www.osgeo.org, 02-05-2013).

A major choice of technology for our PPGIS application is between ESRIs ArcGIS Server and Open source, because NCA has implemented a full SDI (Spatial Data Infrastructure) including both ESRI and Open Source. Open source web map servers are available for free, and a lot of support is available on the web, however professional personal support is only available by payment as a part of enterprise support. Many IT-developing companies offer such supports on the open source technologies (geoserver.org, 02-05-2013).

MapServer (www.gisdevelopment.net, 20-05-2013) GeoServer (workshops.opengeo.org, 20-05-

2013)

Figure 12: System architecture of MapServer and GeoServer

The best-known web map servers are MapServer and GeoServer (Steiniger and Hunter, 2013). Both servers conform to web mapping standards as WMS, WFS, WCS and GML. Both servers support vector, raster and mainstream geodata (data source and layers) formats, like shape, GeoTIFF, PostGIS, etc. MapServer runs as a Common Gateway Interface (CGI) application within the Apache environment. GeoServer is built on Java technology and runs in Apache Tomcat web server environment which XAMPP supports. GeoServer publishes data from any major spatial data source using open standards. GeoServer features include a

32

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

majority of the available service standards and an integrated Openlayers client for previewing data layers (geoserver.org, 03-05-2013). Web map server architecture of MapServer and GeoServer is compared in Figure 12. According to Ballatore, et. al. (2011), MapServer is stronger at performance, scalability and stability, while GeoServer is easier to extend, and follows the various web mapping standards more closely. As GeoServer is a part of NCA’s Open Source SDI and major part of our MTM technology course, we choose GeoServer as the primary open source application server in this project.

As alternative to open source system, ArcGIS server represents the commercial web map server. Purchasing ArcGIS-software will give free access to support for installation and some development, both on web and personal support, however utilizing the services for mobile applications, imply to purchase the most expensive version – ArcGIS for Desktop Advanced or organisation account (www.esri.com, 07-05-2013). System architecture of ArcGIS Server is illustrated in Figure 13. A detailed comparison of GeoServer and ArcGIS server is listed up in Appendix 5. As far as geodata formats support is concerned, ArcGIS 10 provides native support to about 45 geodata formats including raster data, but not PostGIS (resources.arcgis.com, 21-05-2013). ESRI and Safe Software have integrated FME into ArcGIS and produce ArcGIS Data Interoperability extension for Desktop, which can support up to 147 different geodata formats, including CAD, PostGIS, MS SQL and Oracle spatial databases (resources.arcgis.com, 22-05-2013). The extension is only available as add-on purchase.

Another important change in the recent years is the cloud hosting and cloud computing. ArcGIS online is a typical cloud example in the GIS field. ArcGIS Online provides ArcGIS users with a set of foundation services that is deeply integrated with ArcGIS. It publishes users GIS data as feature services directly from within ArcGIS Online, or as hosted feature services using ArcGIS 10.1 for Desktop. The published services are hosted in ESRI's secure cloud and user can maintain all ownership and rights. From the cloud, user can either keep the data private within his organisation or share them publically for others to use.

Figure 13: System architecture of ArcGIS Server (webhelp.arcgis.com, 25-05-2013)

33

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The ArcGIS Online is available through both no-cost and subscription licenses. The free license has a limitation of 1000 GIS objects (or GIS features in ESRI’s term).The architecture of ArcGIS online in Figure 14 illustrates how the participating software components are divided into logical layers and physical tiers.

Figure 14: Architecture diagram of ArcGIS online (resources.arcgis.com, 23-05-2013)

4.1.3 Map Transformation

Geographic data are usually shown on flat screens or paper, a projection has to be made from the circular grid. The grids make reference possible in one, two or three dimensions for an object. A fourth dimension often added is time.

In Norway the datum WGS849 / EUREF8910 is the main geodetic reference used for geographic data (Figure 15), however some data might still use ED5011 as reference, for instance offshore operations connected to

9 WGS84. World Geodetic System. uses the EGM96 (Earth Gravitational Model 1996) geoid

34

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

petroleum industry mainly use ED50, as this is de facto and de jure reference for licenses and surface and subsurface facilities (npdwms.npd.no, 17-04-2013).

WGS 84 (commons.wikimedia.org ) UTM zones (www.ibm.com)

Figure 15: Typical map projections used in Norway

The most common projection in Norwegian waters is UTM (Universal Transversal Mercator), with the northern hemisphere zones 31 - 36 including Svalbard utilized. However the zones are for some uses extended like 32V and 33X. As far as a base map or other 3-part background map is concerned, other projections than UTM can be mentioned: OpenStreetMap and Google Map use a Spherical Mercator projection coordinate system; Google Earth uses the WGS84 projection whereas Google Maps uses a close variant of the Mercator projection.

Transformations of position data are needed to combine the positions of the oil spill reports. To combine these data with the other geoservices, background maps and feature sets on the mobile GIS, Web GIS or desktop GIS, geographical position must be transformed to geometry. This transformation can be done either in the database, or in the geoservice application which are presenting the data. Transformation and restructuring of spatial data is however recommended ahead of storage in the spatial database to not decrease performance of geoservices. FME (Feature Manipulation Engine) Server from Safe Software (www.safe.com, 03-05-2013) is a major software package which can contribute with numerous data handlings, manipulating and restructuring, including transformations. This functionality is however also available within database environments and in open source libraries like OGR simple feature library which

10 EUREF89. The European Terrestrial Reference System 1989 (ETRS89) is an ECEF (Earth-Centered, Earth-Fixed) geodetic Cartesian reference frame 11 ED50. European Datum 1950 is a geodetic datum which was defined after World War II for the international connection of geodetic networks

35

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

can be utilized. According to our literature study, both GeoServer and ArcGIS server claim that map transformation is integrated as a server feature. We shall therefore conduct all the map transformations within the web map server.

4.1.4 Database

A database is a collection of data and database management system (DBMS) is designed to administrate/operate the data in database. Compared with typical database, a spatial database requires additional functionalities and spatial data types. In the past decades, two different approaches of development of spatial enabled databases have been tested and applied. The first approach is known as spatial data engine (SDE). With this method, attributes of geodata are saved in a relational database with a unique link to the external spatial elements. The relational database is just a container, as all the operations and transactions of geometry are processed out of the kernel of database. SDE solution separates the spatial elements and geographic objects, and both DBMS and spatial objects can have their unsynchronised development. ESRI’s ArcSDE is a typical example of this SDE approach. The biggest issue of SDE solution is efficiency and interoperability due to the channel mapping. Therefore a new approach, spatial-enabled DBMS, is quickly developed in the recent years. This solution takes geometry data in to the database directly as objects. The DBMS is thus extended as based on object-relational database. Traditional DBMS functionality like indexing, query optimization, and transaction management are supported in a seamless fashion for user-defined data types and functions (Breunig et al. 2003). Without the bridging SDE, performance of the spatial operation is improved significantly. The only disadvantage is that the architecture is bounded to specific database platform.

As for now there are three kinds of derived standards for spatial database and spatial extension development, namely ISO/TC 211, OGC SFSQL and ISO SQL/MM (. The ISO/TC 211 Geographic information/Geomatics standards may specify, for geographic information, methods, tools and services for data management (including definition and description), acquiring, processing, analysing, accessing, presenting and transferring such data in digital / electronic form between different users, systems and locations (www.iso.org, 31-05-2013). The ISO/TC 211 standards are complicated with support to both 2D and 3D elements. OGC SFSQL and ISO SQL/MM standards address only simple 2D elements and define generic types in a SQL environment in order to manage collections of geographic elements, such as points, curves, and surfaces etc.

In this project we are facing with different data sizes and data types, including spatial data, therefore it is important to choose a proper database with spatial-enabled features. The major criteria are data operability and performance. Cost-benefit will be a secondary requirement in consideration. Many open source or free database systems are available today and are tested with millions of applications. As their performances have reached the enterprise level, it is our primary idea to choose the database system from main stream free databases, namely Microsoft SQL Server Express, PostgreSQL, Oracle's MySQL.

SQL Server Express is a free version of Microsoft's flagship database, SQL Server. It provides many of the core features of the SQL Server commercial version with some limitations on scalability, for example, limits on CPU power (one socket with max four cores), memory usage (1GB utilized, despite of more installed)and size of database (10GB). If SQL Server Express is applied in projects in our sizes, the limitations will not be an issue. Major advantages of using Microsoft’s database system are connectivity with other Microsoft products. For example, SQL Express can easily be integrated with other tools like Visual Studio and security

36

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

model of SQL can be connected to Windows active directory. Support for SQL Server Express is available through the Microsoft Developer Network and a variety of online support forums and blogs. The disadvantages can be lack of features compared with its commercial version, such as clustering and the lack of graphic user interface for the administration of database system. In the spatial part of SQL Server Express, both geography and geometry data types are supported with corresponding operating and transaction methods which are defined by OGC. The geography data types, also known as Well-Known Binary (WKB) format, include point, multipoint, linestring, multilinestring, polygon, multipolygon and geometrycollection. The geometry data types, also known as Well-Known Text (WKT) format, include point, infinite and finite lines, rectangular box, open and closed path, circle.

PostgreSQL is an open source database system. PostgreSQL is essentially a relational DBMS, but with an object-oriented database model (Perschke, 2012). PostgreSQL is a feature rich database server and once the software is installed, all features are available. The administrator user interface is very intuitive and easy to navigate. Besides a secure authentication, communication between client and server can be encrypted and furthermore the database itself can also be encrypted using the pgCrypto extension. Documentation of PostgreSQL is extensive. An active community offers support to users. If needed, the PostgreSQL website provides a list over the companies that yield commercial support and hosting. The spatial extension of PostgreSQL is PostGIS, which allows PostgreSQL used as a backend spatial database for GIS. The strength of PostGIS is that it has become the standard backend for most FOSS4G tools (Ramsey 2006). PostGIS supports all FME formats and makes spatial data easy to be analysed, visualised and published on the web via GeoServer or MapServer.

MySQL is one of the most popular open source databases. Large organisations such as Wikipedia, Twitter and Facebook use MySQL (www.mysql.com, 29-04-2013). MySQL is originally developed for Linux operative systems and Oracle has made several improvements in the way MySQL runs on Windows, and it is now truly a cross-platform database. The major advantage of MySQL is web-oriented. Many of the commercial hosting services have built excellent web front-ends to MySQL, making it easy to manage as part of a web solution. Oracle is committed to supporting and updating the core functionality of the community edition of MySQL for the foreseeable future. MySQL security is managed through Access Control Lists for access to all objects and operations. Like PostgreSQL, it supports SSL encryption in data communication between client and server.

Table 6: Comparison of the free databases

Product SQL Server Express PostgreSQL MySQL

Pros Excellent management tools, migration path to commercial offerings

Cross-platform capable, performance, management tools available with install

Cross-platform capable, performance, large installed base, commercial versions and support available

Cons Large footprint, some limits in Express version, not cross-platform capable,

Some counterintuitive syntax; slightly lagging in performance

Some features reserved for commercial versions only, no built-in management tools

Performance ranking

Good Better Best

37

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The disadvantage of MySQL is lack of a management tool. MySQL supports spatial extensions to enable the generation, storage, and analysis of geographic features. Both WKB and WKT data formats are supported, although MySQL stores internally geometry values in a format that is not identical to either WKT or WKB format.

Table 7: Cross comparison of spatial databases

Feature SQL Server 2008 (RC0) MySQL 5.1/6 PostgreSQL 8.3/PostGIS 1.3/1.4

OS Windows XP, Windows Vista, Windows 2003, Windows 2008

Windows XP, Windows Vista, Linux, Unix, Mac

Windows 2000+, Linux, Unix, Mac

Licensing Commercial, Free Express version has full spatial support but limitation on database size and only use one processor.

Commercial Open Source (COSS), some parts GPL. Free software.

FLOSS (PostgreSQL is BSD, PostGIS is GPL Open Source)

Free GIS Data Loaders

shp dataloader OGR2OGR, shp2mysql.pl script included shp2pgsql, OGR2OGR, QuantumGIS SPIT,SHP loader for PostGIS

Commercial GIS Data Loaders

Manifold, Safe FME Objects, ESRI ArcGIS 9.3

Safe FME Objects Manifold, FME Objects, ESRI ArcGIS 9.3

Application drivers for spatial component

SharpMap.NET eventually and probably built into new ADO.NET 3.5+

GDAL C++, SharpMap via OGR, AutoCAD FDO

SharpMap.Net, JDBC postgis.jar included with postgis, JTS etc. tons for Java, GDAL C++, AutoCad FDO beta support

Free Object/Relational Mapping

NHibernateSpatial (this is a .NET object relational spatial mapper)

Hibernate Spatial - this is a java object relational mapper

NHibernateSpatial and HibernateSpatial

Free Desktop Viewers and Editors

Will be built into SQL Manager, but not available in RC0 and only useful for viewing

GvSig OpenJump, QuantumGIS, GvSig, uDig

Commercial Desktop Viewers and Editors

ESRI ArcGIS 9.3 Server SDE later service pack, Manifold, FME

FME ESRI ArcGIS 9.3 Server, ZigGIS for desktop, Manifold, FME

Web Mapping ToolKits

Manifold, MapDotNet, ArcGIS 9.3 (in later service pack), UMN MapServer see, MapGuide Open Source (using beta FDO driver)

UMN Mapserver, GeoServer, MapGuide Open Source

Manifold, MapDotNet, ArcGIS 9.3, UMN Mapserver, GeoServer, FeatureServer, MapGuide Open Source (using beta FDO driver)

Spatial Functions Both OGC SFSQL MM and Geodetic custom (over 70 functions)

OGC mostly only MBR (bounding box functions) few true spatial relation functions, 2D only

Over 300 functions and operators, no geodetic support except for point-2-point non-indexed distance functions, custom PostGIS for 2D and some 3D, some MM support of circular strings and compound curves

Spatial Indexes Yes - 4 level Multi-Level grid hierarchy

R-Tree quadratic splitting - indexes only exist for MyISAM

GIST - a variant of R-Tree

True Geodetic support

Yes - with caveats - must use Geography type which has many constraints

No No

Shared Hosting Many Many Much fewer, but ramping up.

38

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Perschke (2012) have reviewed the performance of these databases as common databases. A comparison chart is listed in Table 6. Boston GIS (2009) has made a cross comparison (Table 7) of SQL Server, MySQL and PostgreSQL focusing on the suitability for spatial analysis, mapping and general GIS processing.

ESRI’s ArcGIS products support actually all the above-mentioned databases and use term “Geodatabase” to describe the spatial DBMS. The three types of multiuser geodatabase are illustrated in Table 8. SQL Server Express is the primary database engine for ArcGIS desktop and ArcSDE is applied in communication with all other kinds of databases, including PostgreSQL and Oracle’s database products. It is actually our plan to apply in parallel with PostGIS and ArcGIS Online as spatial databases, so that we can get a better understanding of the differences between the setups and performances.

Table 8: Three types of multiuser geodatabase used in ArcGIS products (www.esri.com, 08-05-2013)

Enterprise Workgroup Desktop

Application Scenario Large-scale enterprise

application scenarios

Small- to medium-sized

departmental application

scenarios

Small teams or a single user who

requires the functionality of a

multiuser geodatabase

Data Storage Enterprise RDBMS Platform DB2 Informix

Oracle

PostgreSQL

SQL Server

SQL Server Express SQL Server Express

Management Interface

ArcCatalog

RDBMS

ArcSDE command line

ArcCatalog ArcCatalog

Storage Capacity Depends on the server 10 GB 10 GB

Licensing Availability

ArcGIS for ServerEnterprise ArcGIS for ServerWorkgroup ArcGIS Engine

ArcGIS for Desktop Advanced

ArcGIS for Desktop Standard

Supported OS Platform

Any platform Windows Windows

Number of Concurrent Users

Unlimited editors and

readers

10 editors and readers 1 editor and 3 readers

Network Application Intranet and Internet Intranet and Internet Desktop and local network use

Differentiating Characteristics

Supports versioning

Supports multiuser editing

Supportsspatial types

Enterprise IT integration

Supports versioning

Supports multiuser editing

Supports versioning

39

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

4.1.5 Desktop GIS

Both web GIS and desktop GIS can be useful tools for verification and analysis the collected data from citizen’s oil spill reports. But considering the user reports in our case shall be analysed and integrated into the other existing GIS systems, desktop GIS is the best tool as it can works across platforms and networks. It is usually placed at the server side among different servers (Figure 16).

A desktop GIS is often used for management, analysis and publishing of GI-data and GI-services. Desktop GIS has a long tradition from the first software tools were utilized in nature management in the 80’s, e.g. after oil spill of Exxon Valdez in Alaska 1989 (ww.esri.com, 28-05-2013). There are loads of software to use for GIS today, however GI tools are evolving into the web and cloud, and most GI-software know also connect to resources and services on the web/cloud, like WMS and WFS-services, KML-files, and Google Fusion tables. NCA is using ESRI’s ArcGIS as desktop GIS software for accessing different data together with the web-GIS solution Kystinfo.

Figure 16: Desktop GIS's roll in validation and publication of oil spill data

A desktop GIS have generally a high capacity of calculations and analysis, and can store most necessary data locally to support quick and efficient verification and publication. The Desktop GIS can be used to combine the relevant data for design analysis and decision support. In our case, desktop GIS with its high processing resources will be a benefit in report verification because time used for this process should be kept at a minimum. To contact the citizens who have given the reports can also be of high value. Desktop GIS will also be flexible in adding more detailed information, and eventually classification to the original reports. Furthermore, standard automatic routines for verification can be easily set up based on Model builder and

40

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Python modules in ArcGIS, where Python is the most used script language to run processes, and Model builder is a visual tool to set up a process of many routines to be run when needed.

4.2 Smartphone applications The client side of our PPGIS application refers primary to a smartphone. In this chapter, the main technical concerns of development to a smartphone will be discussed. Such a discussion will reveal the major considerations behind our choice of programming tools at the client side.

4.2.1 Mobile application with GIS features

Mobile technologies are developed based on mobile communication. Mobile computing with wireless networking is the key feature of mobile technologies. In this new millennium, the evolution of silicon has made the mobile units smaller, and more powerful. Many of the new components, such as GPS (Global Positioning System), camera and WiFi (Wireless Fidelity), have been integrated into a phone size mobile unit. The innovation on the hardware is frequent and rapidly changing. On the other hand, common use of applications is becoming the major driver to the technology development. With popularization of the internet, online search and online purchase has boosted the development mobile applications. There are three major types of mobile apps, namely native apps, web apps and hybrid apps.

Native apps are built for a specific platform with the platform SDK (Software development Kit), tools and languages, typically provided by the platform vendor, for example, xCode/Objective-C for iOS (iPhone Operating System), Eclipse/Java for Android, Visual Studio/C# for Windows Phone (www.icenium.com, 04-05-2013). Native apps have thus no cross-platform ability. Native apps can access and utilize all the internal functions in a mobile phone, and they runs smoothly as it is written in the same language as operative system does. In principle native apps shall give the best performance. It is a good idea to use the native app, if large amount data or advanced graphic shall be presented.

Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor (www.icenium.com, 04-05-2013). In principle web apps are not real applications, but websites that is customized or optimized to show on mobile units. Development of web apps is by far the fastest approach for cross-platform presentation. Web apps can look and feel like native apps, but they are 100% rely on the onboard web browser and network connections. Network delays will be the bottleneck for the performance that programming cannot overcome. The ability to access local storage is also very limited, as programming cannot reach the high end of the local file hierarchy. If there is short of developing hours and the apps shall be presented in different platform, web apps are smart choices.

Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage (www.icenium.com, 04-05-2013). The secret of hybrid apps is to utilize native browser engine accessing device capabilities/native APIs (Application Programming Interface). By that mean, cross-platform capabilities are inherited from web apps and more local functions are available for the application without native programming. Despite of the advantages of the combination of web and native, hybrid apps cannot gain the local access at the same level as native apps, in other words, limitation of the local access is

41

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

still limited. Network delays or limitation can be solved by workarounds like offline cache, but it becomes an issue if the cache data are in mega sizes.

Technology issues of the three types of apps are compared in Figure 17. Key features of different apps are listed in Figure 18. All types of apps have their advantages and disadvantages. In our opinion, the principles for apps choice are target user group, purpose of the application, requirements on the network connectivity and data size.

High Native Apps Hybrid Apps

Single platform affinity Written with platform SDKs Must be written for each platform Access to all native APIs Faster graphics performance AppStore Distribution

Cross-platform affinity Written with web technologies

(HTML5, CSS3 and JavaScript) Runs locally on the device, supports

offline Access to native APIs AppStore Distribution

Mobile Web Apps

Cross-platform affinity Written with web technologies (HTML,

CSS, JavaScript, or Server-side (PHP, ASP.NET, etc.))

Runs on webserver, viewable on multiple devices

Centralised updates

Low Platform Affinity High

Figure 17: Comparison of mobile apps in technology aspects (www.capaxglobal.com, 29-04-2013)

Access to Device Capabilities

42

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 18 Comparison of the key features of mobile apps (www.looksoftware.com, 23-04-2013)

In order to decide whether a web part shall be included into our application, we have to take GIS features of a mobile app into account. Web-GIS application produces the interface between GIS information and the individual user, by showing geodata and tools on a smartphone screen. Web GIS shall bring functionality from the traditional Desktop GIS to the web, with minimum installation and software at client side. Fu (2011) refers to four main factors when establishing a Web GIS application: Performance, Scalability, Availability and Security. In our opinion, available process power client-side is important to highlight, as well as the level of system complexity needed on the Web GIS. For example, there are many web browser add-ons that can be installed client-side and give browser access to the GIS functionality; however those require extra process power from smartphone and a level of knowledge from user to accept. Therefore, the add-ons may not be necessary in our consideration.

Our PPGIS application is designed to promote the GIS application to all citizens - GIS-specialists as well as any unqualified user. Even though ordinary citizens’ common spatial awareness is increasing by using Google Earth and other web and mobile GIS-applications, our app is design to basic users aiming at intuitive and smooth interfaces adjusted to their requirements. We have therefore chosen a mobile web apps to start with.

HTML5 (Chapter 4.2.2), CSS3 (Cascading Markup Language 3, Chapter 4.2.3) and JavaScript (Chapter 4.2.4) are the three musketeers in development of mobile applications. These elements are further discussed in the following chapters. In order to provide a scalable and flexible across platform mobile app strategy to all different type of purposes, architecture must be designed. W3 Cubes (2013) have presented their anatomy

43

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

of a HTML5 app (Figure 19), where HTML5 is backbone of the app with CSS and JavaScript as two assistants. Concerning the technical realization, we are very much inspired by the stack.

Figure 19: Example of anatomy of a HTML5 Mobile App (w3cubes.com, 2013)

4.2.2 HTML5 (Hypertext Markup Language)

Smartphone runs on different operative systems such as Android, iOS and windows. Without mastering JAVA, Objective C or C# programming languages, we need to start a cross platform app development with HTML5. HTML5 stands for Hyper Text Markup Language version 5. A markup language is a set of tags that describe the document content. HTML uses tags such as <h1> and </h1> to structure text into headings, paragraphs, lists, hypertext links etc. HTML documents are often referred as web pages and contain both tags and plain text. The first version of HTML emerged in the late 1990’s and developed together with the popularization of the World Wide Web. While the HTML was developed to version 4 in 1997, the emergence of new classes and features influences the HTML so much that the W3C (World Wide Web Consortium) sees the necessity for Extensible Hyper Text Markup Language(XHTML). In 2007 W3C started up a XHTML working group to fulfill the promise of XML for applying XHTML to a wide variety of platforms with proper attention paid to internationalization, accessibility, device-independence, usability and document structuring. In December 2012, W3C announced the 5th revision of the HTML standard, HTML5. It claims to be an improved language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices. HTML5 is an attempt to define a single markup language that can be written in either HTML or XHTML syntax.

44

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Freeman (2011) understands HTML5 as an umbrella term that describes a set of related technologies that are used to make modern, rich web content. The new standard brings the following opportunities:

• Embracing Native Multimedia: HTML5 supports playing video and audio files natively in the browser without plugin. This integration between the native multimedia support and the rest of the HTML features means even more new technology possibilities.

• Embracing programmatic content: Addition of the canvas element makes programming a first-class activity in a HTML document, because canvas allows dynamic, scriptable rendering of 2D shapes and bitmap images. Besides canvas, HTML5 specifies scripting application programming interfaces (APIs) that can be used with JavaScript. These new APIs enables functionalities such as web storage (dev.w3.org, 15-04-2013), offline web applications (www.w3.org, 30-05-2013), cross-document messaging (dev.w3.org, 23-04-2013). A detailed description of HTML5 related APIs is illustrated in Figure 20.

• Embracing the semantic web: HTML5 introduces a number of features and rules to separate the meaning of elements from the way that content is presented.

HTML5 is now supported by the most popular web browsers. The number of sites that use HTML5 feature is growing rapidly. According to binvisions.com 2011, 34 of the world’s top 100 websites were using HTML5 – the adoption led by search engines and social networks (www.binvisions.com, 30-04-2013).

The most interesting point of HTML5 is the programmatic feature. This can helps us to deal with many of the technical difficulties like offline web application and offline cache, which are mentioned in Chapter 4.2.1.

Figure 20: HTML5 related APIs (Mavrody, 2012)

45

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

4.2.3 CSS3 (Cascading Style Sheet)

If HTML5 makes possible to create a universal application on smartphone, CSS3 will bring the application layout to a more professional level. CSS stands for Cascading Style Sheets. It is a style sheet language used for describing the presentation of web pages, including colours, layout and founts (www.w3.org, 26-05-2013). By using CSS, the presentations of a website can be adapted to different types of devices, such as pc screens, mobile screens, or printers. CSS is not HTML itself but is compatible with any markup language. The structure separation of content (HTML) from presentation (CSS) makes site updating much easier.

The development of CSS language is boosted by the competition from browser market. When Internet Explorer is no longer dominate in the browser market, every browser wants to offer developers and users the latest in web technologies in form of presenting new features. CSS can fulfil the demands as the specifications are written and implementations are proved. All web browsers support CSS in different extent. Detailed information of CSS supporting in web browser can be found in Appendix 6.

CSS is now released in level 3. CSS3 defines various features in separate modules. Capabilities and features of each module are defined by the CSS work group in W3C. Due to the modularization, different modules have different stability and statuses. As for now, four modules have been published as formal recommendations: Media Queries, Namespaces, Selectors Level 3 and Colour. The advantages and disadvantages of integrating CSS3 in web pages are listed in Table 9.

Table 9: Pros and Cons of CSS (www.vordweb.co.uk, 29-04-2013)

Advantages Disadvantages

• Easy changes in the layout The layout of a web site can be changed beyond recognition just by altering the CSS file, which makes CSS indispensable for large web sites.

• File Size HTML file is smaller without the style and layout contents; Bandwidth is reduced as CSS file need only to be downloaded once and can then be reused.

• Search Engines With a CSS page the navigation of search robot can be moved to the bottom of the source code, so the search engine displays your content instead of your navigation.

• Accessibility Separating style from content makes easier for those who use a screen reader to interpret a page.

• Consistency Layout and position of navigation can be completely consistent across a site.

• Browser Compatibility CSS does not work consistently in different browsers. Different modules are supported by web browsers in different way.

CSS is an interesting technology in our project, because we will present vivid and fluid user interfaces that fit to all kinds of mobile screens. The media queries in CSS will just satisfy our needs. It allows developers to tailor to different resolutions without changing of content (Figure 21).

46

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 21: Example of a CSS layout in different screen size (www.1stwebdesigner.com, 02-05-2013)

4.2.4 JavaScript

HTML5 and CSS3 together give the developers some serious designer credibility, as HTML5 comes with a semantic structure and CSS3 supplies with layout empowerment. JavaScript can supply HTML5 with many powerful functions, by that more functionalities in smartphone apps. JavaScript (JS) is an interpreted computer programming language with object-oriented capabilities (Flanagan, 2006). JavaScript becomes the most commonly used in web browsers with the rise of HTML5. This is because HTML5 adds a lot of new features to the web pages, but many of them are unusable in the absence of JavaScript. JavaScript is implemented as part of web browsers so that client-side scripts could interact with the user, control the browser, communicate asynchronously, and alter the document content that was displayed (Flanagan, 2006).

In web browser’s context, JavaScript is a client side language, which means it works within the client side (web browser). JavaScript can react immediately and change what a client sees in the web browser without the need to download a new page. The actions includes making content appear or disappear, moving around the screen, updating the content automatically based on the client’s action.

JavaScript is a scripting language, which is easy to be understood and learned by web designer. Due to the size and complexity, creating and testing scripts is relatively easy and fast processes compared with other desktop programming, such as C#. In contrast to compiled languages, JavaScript is only compiled when an interpreter reads the codes. JavaScript interpreter is normally built into the web browser, and it translates the JavaScript into something the computer understands. The challenges of this compiling method underlie in two aspects, namely cross-browser compatibilities and execution performance. All the major web browsers like Internet Explorer, Chrome, Firefox, Safari and Opera support JavaScript (www.javascripter.net, 29-04-2013). Each web browser has its own embedded JavaScript interpreter and the compatibility relies on how many features or classes are supported within the interpreter. Web browser expects usually HTML and JavaScript is added into HTML by using tag pair <script> and </script>. When web browser reads the tag <script>, the following codes are handed over to JavaScript interpreter,

47

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

which translate to the executable computer coding. As JavaScript codes are first compiled when they are executed, the execution speed is relatively lower than the compiled languages. The difference is however marginal in user experiences.

For non-programmer like us, programming is hard just like learning a foreign language. Actually many of the functions we want to realize in our mobile application can be found in similar applications. It will be nice if we can borrow some of the codes for adaption. On the one hand, these codes are tested to be functioning. On the other hand we can get a jump-start and save programming time. The opportunity is fortunately offered by JavaScript libraries, which provide simple solutions to many of the day-to-day details of JavaScript. jQuery is one of these popular JavaScript libraries. Figure 22 illustrates the major benefits by applying jQuery in JavaScript programming. jQuery is supported by a large developer community and is small sized, user friendly, CSS3 compatible and most attractive – it is free.

Figure 22: Advantages by applying jQuery in JavaScript programming (try.jquery.com, 29-04-2013)

4.3 PPGIS interaction tools In order to find out the applicability of technologies described above, we have carried out a literature study on PPGIS interaction tools. Many mobile applications are found, either with a similar purpose or with a similar design method. However, an app that can directly fulfil our requirements is not found. As inspirations of our system design, we have picked up three examples, one is oil spill related and the others are for illustrating the user interaction.

4.3.1 PPGIS and Crowdsourcing

PPGIS

The term PPGIS was presented at the International Conference on Empowerment, Marginalization and Public Participation GIS, Santa Barbara, California 14-17 October 1998 for a the purpose to utilize GIS technology to support public participation. GIS should be utilized for communication with the public in general instead of being an academic technology for the few. Involving general citizens with PPGIS should assist the creation of new knowledge, where especially marginalized groups could be included.

PPGIS have later also been grouped into different categories, according to who the government connects to. G2C refers to a PPGIS set up for communication with citizens in general, while G2E on the contrary is set

48

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

up for connection between government and its own employees, and G2B refers to a government to business connection (Hansen and Prosperi, 2005).

As the suggested Smartphone PPGIS should connect to citizens in general (G2C) it is also of interest to see into Arnsteins ladder of public participation (Hansen and Prosperi, 2005), which refer to different levels of participation. We have in our previous study (Verup et al., 2013) pointed out “Tokenism” as the level of public participation relevant for a PPGIS on oil spill situations, tokenism defined as “public participation in defining interests, actors and determining agenda”. As the oil spill emergency response mainly is based on professional decisions, which can include such critical issues as to deny a troubled and possibly sinking ship a place of refuge, the level of participation from the public should not be a full participation.

The general knowledge of GIS and level of spatial awareness have increased the last years with new technologies like Google Maps and Google Street View also present as smartphone applications. A High public engagement in recent oil spill situations, together with the increase public spatial awareness have prepared the ground for a Smartphone PPGIS for oil spill information exchange.

Crowd sourcing and Volunteer Geographical Information (VGI)

The term "crowdsourcing" is a combination of "crowd" and "outsourcing," coined by Jeff Howe in 2006. “Crowd-sourcing is a process that involves outsourcing tasks to a distributed group of people. This process can occur both online and offline, and the difference between crowdsourcing and ordinary outsourcing is that a task or problem is outsourced to an undefined public rather than a specific body, such as paid employees” (Lee et al., 2012).

VGI from crowd sourcing brings with it many benefits and its use is likely to continue in the coming years. However it relies on voluntary contributions. VGI lack a quality assurance regime widely recognised by the broader user-base of geospatial information, hence it is not expected to remove the need for a wide range of core, quality-assured, geospatial information. Governmental authorities however, may take a role of developing quality assurance mechanisms and standards for VGI data so that a level of authority can be included with VGI data (UN GGIM, 2012). This is very much a parallel thinking to our use of information gathered from affected citizens.

Since the requirements of our system finds its parallels in many existing PPGIS and Crowd sourcing, we have chosen to review relevant existing PPGIS

4.3.2 PPGIS and the Deepwater Horizon oil spill in the Mexico Gulf

The Deepwater Horizon drilling rig explosion occurred on 20th April 2010 at the Macondo prospect in the Mexico Gulf caused oil to emerge from the open wellbore until 15th July (Figure 23). This caused the US biggest oil spill information exchange ever. In this situation ESRI launched many GIS-tools in order to provide assistance to many different governmental agencies as well as private participants during the emergency period. They were using GIS for situational awareness, data collection, and analysis. ESRI refers to several user benefits of GIS experience during the oil spill information exchange (www.esri.com, 28-05-2013):

"By using GIS technology, field information can be processed into products [that are] useful in the incident command decision-making process." (David Gisclair, from Louisiana Oil Spill Coordinator's Office)

49

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

"For example, they built a product for the state leadership that reflected information on engineering projects, such as breakwaters, Tiger Dams, and sandbagging operations. All this was done on a daily basis, and products were updated continuously as information became available." (Lt. Col. Roy Worrall, Incident Awareness and Assessment (IAA), supporting civil authorities, U.S. Army National Guard)

"Alabama used ArcGIS Mobile 10 to collect the locations and condition of deployed booms. The application allows the marine police and resources officers to stream GPS coordinates to a laptop, attribute the line, and edit the attributes. The data is sent to a server in near real time to provide the data to the planners" (Lynn Ford, GIS manager for the Alabama Department of Environmental Management)

Figure 23: Satellite photo of oil spill situation in the Mexico Gulf 14th May 2010 (www.youtube.com, 03-05-2013)

50

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

As a major tool, ESRI had set up a disaster response web site (Figure 24) including an interactive map application that allowed users to add VGI in the form of links to online photos, web sites, and YouTube videos. By doing so, volunteers could add current information to the map and increase everyone's awareness of activities related to the spill. ArcGIS Online was also used to rapidly set up portals for situational awareness after the Deepwater Horizon accident. The applications, services, data, and maps shared via ArcGIS Online assisted the response efforts and helped meet mitigation requirements. The site also included links to relevant map services and downloadable data, maps, and layer packages. Services included an oil spill plume trajectory model, an environmental sensitivity index map, and electronic navigation charts.

In this case, ESRI’s web site had acted as a web GIS container that includes all the relevant maps, applications and multimedia documents. It is not a mobile application itself, but the contents and procedures are inspiring to this study.

Figure 24: Contents of ESRI's web site as information exchange to Deepwater Horizon’s oil spill in 2010

4.3.3 Other relevant GIS-applications

In Chapter 4.3.2 we have given examples of WEB-GIS applications concerning oil spill information exchange in the context of involving and informing the citizens. In this chapter we present two mobile applications that inspire us on the layout design. Both applications are aiming at public participation.

Applications to report pollution incidents and deviations

The Smartphone application “See it? Say it!” is developed by the Environmental Protection Agency (EPA) Ireland to make it easy for the public to report environmental pollution in their local area, and is a good example of mobile applications developed to facilitate interactions between citizens and authorities. The functionality in the application is based on taking a photograph, adding a few simple details including contact details, and then submitting the complaint. The details of the complaint, such as location, nature of the complaint etc. is then passed to the relevant local authority, and followed up by them. The application is only available for use on devices running iOS operating system and can be downloaded from the iTunes APP store directly, or by scanning a QR code on the EPA’s homepage (www.epa.ie, 06-04-2013).

51

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 25: Mobile app See it? Say it!, developed by the Environmental Protection Agency Ireland make it easy for the citizens to report environmental pollution

As shown in Figure 25, the input interface is simple and clear. Key information is collected in a single page in a telephone screen size. Textbox is designed for user defined text and dropdown box minimizes the input error and helps with the correct categorization. These can be learned as element design in our layout.

Applications supporting decision making and knowledge-increasing

The application “Naturmobil Bornholm” was initially developed as a one-way information application (authorities -> public) regarding natural and cultural values at the Danish island Bornholm in Baltic Sea, and in cooperation between Landskabsværkstedet12, Bysted AS13 and local environmental authorities. The main goal for the solution, which was developed in connection with a public meeting, was to show the environmental and cultural values, hiking routes etc. for the public in a modern and easily accessible manner. In addition to this, the application also provides users the opportunity taking photos and share them with other users of the application or on Facebook.

Beyond this more or less “randomly” interaction with citizens and users, the cooperation is now planning a development that will support the ability for users to collect proposals for facilities and trail location in a larger regional trail project in Roskilde, Greve and Solrød municipalities. I addition to this, the user should also be able to record their knowledge or tell little stories about places or point of interests along the trail. The process can then combine the collection of both suggestions and user generated knowledge about the local area (Præstholm, 2012).

As shown in Figure 26, the presentation of geodata is listed in point to details format. This keeps the overview nice and clean, but still with possibilities to display a full story to them who are interested in a single topic. This two levels of layout in presenting data shall also be considered in our design.

12 Landskabsværkstedet: http://www.landskab.nu 13 Bysted AS: http://www.bysted.dk

52

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 26: Layout in application “Naturmobil Bornholm”

The three examples of PPGIS applications given above can be used as inspiration for our application in terms of design, flow, layout, etc. Esri-apps provide a proposal for how GIS professions handle oil disasters; See it say it demonstrates how simple an app can be; Nature Mobile illustrates how GIS data can be presented in a simple layout.

4.4 Technical challenges As described in Chapter 4.2 and 4.3, the Smartphone application can be designed in a server-client structure with advantages. Communication between server and client occurs via mobile telephone networks as well as WiFi. Oil spill report text, image data and geographic information are stored into databases, and validated. Design of the Smartphone GIS application constrains on the technology development in all those aspects. Major challenges in our project come from hardware of the mobile equipment and mobile network. These technical issues and challenges are discussed in the following subchapters.

4.4.1 Units in smartphones

With the development of silicon technology, smartphones are getting smaller while more components are put into the little smartphone. As shown in Table 10, more than 95% of the smartphone models have a GPS receiver and a camera integrated. A higher percentage is even found for voice recording.

As far as operative systems are concerned, Android is dominating in the smartphone market (Figure 27). It is in accordance with the interview results from our analysis (Verup, et. al, 2013). As indicated in Table 10, an interesting tendency can be addressed that more smartphone models are now running with windows platform compared with Symbian and Blackberry OS. The diversity of operative system of smartphones brings the challenge of cross-platform compatibility. The purpose of PPGIS is to reach most of the citizens; therefore our mobile app must be functioning on most or all the smartphones.

53

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Table 10: Hardware and software that are integrated in smartphones (www.findthebest.com, 04-05-2013)

Subjects Number of models out of the 520 models included*

Equipment

GPS-navigation 470

Rear facing camera 493

Front facing camera 251

Camera autofocus 399

Camera Digital Zoom 247

Video recording 474

Microphone 495

FM receiver 256

FM transmitter 20

Operative system

Android OS 367

iOS 4

Blackberry OS 34

Symbian 19

Windows 52

Wireless Conductivity

4G mobile broadband 162

3G mobile broadband 466

EDGE/2G 484

Wi-Fi 485

Bluetooth 514

* The frequency of every model is not considered in this statistic.

54

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 27: IDC Worldwide smartphones shipments, Q4 2012 (techland.time.com, 2013)

When we look at wireless conductivity, more than 90% of the smartphones have both Wi-Fi and 2G mobile networks. This is the fundament of how the wireless communications can be built up in our mobile app.

Unit integrations bring not only new functions into smartphones, but also more limitations from corresponding hardware. Major challenges in smartphone used as a telephone lie in battery life and mobile network coverage.

Development of battery technology is far slower than the silicon technology. This means battery capacity is a serious constraint for many mobile devices. It prevents high-power processors or components being used in smartphones. Carroll and Heiser (2010) has analysed power consumption in smartphones and indicates power consuming processes like long periods Wi-Fi usage will quickly drain the battery (Table 11). Short battery life is simply the bottleneck of the hardware. Therefore a reasonable battery load of our mobile app shall be taken into account seriously, as our application will cover web, network, GPS and photo taking/blitz.

Table 11: Power consumption in a smartphone (a benchmark)

Benchmark Power consumption (mW)

Suspend 103.2

Idle 333.7

Phone call 1135.4

Email (GPRS) 690.7

Email (WiFi) 505.6

Web (GPRS) 500

Web (WiFi) 430

Network (GPRS) 929.7

Network (WiFi) 1053.7

Video 558.8

Audio 419

Bluetooth 504.7

GPS (internal antenna) 143.1

55

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Mobile network coverage is another constrain for smartphone, as most of the mobile apps are totally or partly rely on the wireless communication (typically GPRS). GPS navigation in a smartphone is also dependent on the mobile network communication (Chapter 4.4.2). Mobile network coverage always have weak eventually blind areas and these areas are unfortunately also present near the coast, where the Smartphone app shall be used (Figure 28). Therefore offline cache facility shall be considered in the smartphone app.

Figure 28: Mobile network coverage in southern Norway, with detail around Arendal (www.telenor.no, 03-05-2013). 3G net present most areas, however missing in minor parts (light green coloured). 3G have also much less coverage in northern parts of Norway

4.4.2 Mobile GPS precision

From smartphones, location can be calculated in many different ways. The most obvious is the GPS-unit included in most of today’s smartphone models. As of April 2013, 470 out of 520 smartphone models include a GPS unit (Table 10). The GPS unit calculates position by information received from the GPS-satellite system, typically an American military global navigation system (GNS). In regular GPS, reading and calculating the location takes 2 to 5 minutes (www.edepot.com, 03-05-2013), however this will vary based on whether there are a free satellite line to the GPS unit.

Due to the size limitation of a mobile phone, almost all of the smartphones use A-GPS. A-GPS describes a system where outside sources, such as an assistance server and reference network, help a GPS receiver perform the tasks required to make range measurements and position solutions (LaMance, DeSals and Järvinen, 2002). The concept of A-GPS in smartphones is illustrated in Figure 29. Like all the other GPS receivers, signals from at least 3 satellites will be needed for locating a 2D position. With signals from a 4th satellite, elevation can be determined in A-GPS (Zandbergen &Barbeau, 2011).

56

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure 29: The A-GPS concept (Djuknic & Richton, 2001)

Assistance server plays an important role in operation of A-GPS system. The A-GPS server equips with its own professional GPS receiver that is free for any signal loss issues. The server has also the computing power that is normally located in a standalone GPS handset to interpreted GPS signals to position. The A-GPS module in a smartphone contains only a radio and signal processor. The GPS signal received on a smartphone is sent via wireless network (mobile network or Wi-Fi) to A-GPS server for interpreting. After A-GPS server have performed the necessary math and conversions, the server send a map location back to the smartphone via wireless network. A study from Zanbergen and Barbeu (2011) has confirmed the reliability of A-GPS on mobiles phones as a source of location information for a range of different LBS (Location Based Services) applications. In the static outdoor testing, the precision of mobile GPS (A-GPS) is within 5-30 meters. Error in indoor testing does not exceed 100 meters.

A single comparison between A-GPS and a standalone GPS is shown in Table 12. Despite of all the advantages, A-GPS has also its downsides. A-GPS can be totally relied on assistance server and wireless network. Some of mobile GPS don’t work at all without a network connection, which means locating problems in places outside the service areas. In addition, there is a big issue on privacy, as assistance server can track and log all the locations of any single mobile GPS.

In our case, oil spill reports from citizens rely on the precision of A-GPS that is built in to the smartphones that they own. The precision may therefor varies up to 30 meters. However, oil spill scenario at sea spreads typically in square kilometres; mobile GPS precision is good enough for identifying the polluted area. In this project, we estimate a precision of 50 meters will be good enough since oil pollutions cover usually a big area and are easy to see.

57

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Table 12: Comparison between A-GPS and GPS (www.diffen.com, 10-04-2013)

A-GPS GPS Source of triangulation information:

Radio signals from satellites and assistance servers e.g. mobile network cell sites

Radio signals from GPS satellites

TTFX (Time to first fix)

A-GPS devices determine location coordinates faster because they have better connectivity with cell sites than directly with satellites.

GPS devices may take several minutes to determine their location because it takes longer to establish connectivity with 4 satellites.

Reliability: Location determined via A-GPS are slightly less accurate than GPS

GPS devices can determine location coordinates to within 1 meter accuracy

Cost: It costs money to use A-GPS devices on an ongoing basis because they use mobile network resources.

GPS devices communicate directly with satellites for free. There is no cost of operation once the device is paid for.

Indoors ability: Pretty good with mobile network Poor Usage: Mobile phones Cars, planes, ships/boats, etc.

4.4.3 Mobile image quality

A camera phone is a mobile phone equipped with an image sensing device and associated post-processing electronics (Jin, 2008). Most of the mobile phones on the market include a compact digital camera and mobile photography is becoming a fashion, especially among young people. Our mobile application allows users to upload pictures to explain the type and extent of oil spills. Mobile image quality is thus essential to oil type judgment of and data validation. In order to determine image quality, we must know some of the basics of digital photography.

• Pixel and Megapixel: A pixel is abbreviation for Picture element. It can also refer to one dot on a video screen. Each pixel restores a piece of colour information. A megapixel is 1,048,576 pixels. More pixels result in higher image resolution.

• Pixel size: Pixel size stands for pixel quality. A bigger pixel size result in better sensitivity to light and produces stronger image signal. Stronger image signal improve image quality, better colour fidelity and less noise due to improvement in signal to noise ratio.

• Image Sensor: An image sensor is a device that converts an optical image into an electronic signal. There are two types of image sensors: CCD (Charge Coupled Device) sensors and CMOS (Complementary Metal Oxide Semiconductor) sensors. CMOS is the most popular sensors used on camera phones because of its small size.

In general, higher pixel together with bigger pixel size will give higher image quality. But the phone camera has its limitation on size. On one hand camera phone is pursuing higher pixel. Pushing more pixels on a given sensor chip results in smaller individual pixel size. This means lower quality sensor resulting to increased noise level, lower dynamic range, reduced colour fidelity and finally poor image quality (www.stsite.com, 09-04-2013). On the other hand, camera phone has a trend getting thinner and the camera module must be made relatively smaller. Smaller image sensor makes difficult to gather more light and information about the quality of the light. Especially in the dark circumstances, will small image sensor

58

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

produce poor images in terms of "noise" and "dynamic range" (www.easybasicphotography.com, 09-04-2013).

Another important factor that affects mobile image quality is compression, or file format. After image is captured by the optical module and converted into digital signals by image sensor, it can be saved in various formats, for example, jpeg, tiff, bmp, gif and so on. The main difference between these formats is whether the picture is compressed. A standard photo taken with a 2 megapixel phone camera has 2 million pixels and each pixel needs 3 bytes to store the colour information (www.digital-photo-secrets.com, 09-04-2013). An uncompressed image needs therefore 6 MB of storage place. By using jpeg format the file size can be reduced down to 600 KB. Jpeg is the most popular file formats used in phone cameras, because it is flexible in compression ratio and supported by all image related software. But any compression of image file will reduce image quality, including jpeg format.

As users of our mobile application are not professional photographers, mobile image quality in the report can vary, eventually reduce the reliability of the whole report. Moreover, if image recognition is integrated in our mobile app in order to identify oil spill type automatically, mobile image quality will be essential to the process. In this study, we accept all kinds of mobile image qualities. In the future field tests, a screening of the image quality may probably lead to an improvement of the Smartphone PPGIS. As our application and data delivery over the network are concerned, it is necessary to keep the image quality high with data files low.

4.4.4 Metadata for mobile images

Mobile phones can be a powerful system for distributing data between users and experts, and therefore is it important to consider the use of metadata. Mobile phones that delivers coordinates, will also deliver a given precision every time, and that accuracy is metadata. The general understanding of Metadata is strictly defined as data about data, which can be information about quality, source, and format and so on. Metadata for mobile images can be categorized into personal tagging or geotagging. Personal tagging is often used in album or social media to identify people, date and place. Example of personal tagging appears typically album software such as Adobe Photoshop Album. For example, one photograph may have metadata (Sarvas, 2005):

• People: Uncle Matt, Roger, Mike, John Smith. • Event: Mike’s 13th birthday. • Places: Home.

Geotagging is to geographically encode a digital photograph. Data for geographic location refer normally to coordinates as latitude and longitude. But altitude, compass bearing and other fields may also be included as geotags. The EXIF header (the photographic information header of digital photo) has the ability to record the latitude, longitude, altitude and face direction. There are four different methods for geotagging a photo (www.rideau-info.com, 09-04-2013)

• Manual, no GPS: Either a detailed topographic map with latitude and longitude or Google Earth can help us to identify the geographic locations. Coordinates obtained can be manually tracked and then entered into the photo.

59

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

• Automatic, no GPS: This method is based on the built-in geotagging function in photo album software. For example, we can select "Tools > Geotag > Geotag with Google Earth" option in Picasa to geocode a photo automatically.

• Manual, GPS: If we have a camera and a GPS unit, the geographic information can be manually associated to every photo we have taken.

• Automatic, GPS: Most of the smartphones has built in both a GPS and a camera. The fast and simplest way to geotag photos is therefore select the geotagging options in the camera setting. As long as there is connection to mobile network and satellite, GPS on smartphones will stamp photos with corresponding geographic information. If we are not satisfied with GPS precision, we can always correct manually by using software like Google Earth.

In theory, every part of a picture can be tied to a geographic location, but in practice, there is only one position is associated with a single digital image - the point position of the photographer. This makes easy for search and retrieval.

As not every camera phone have automatic geotagging function, metadata of mobile image can only be used as optional or auxiliary info. In our design both personal tagging and geotagging will be submitted to server when they are available. Personal tagging helps to identify the user, while geotagging helps to locate the accident area.

4.5 Summary of GI technology Technical possibilities and challenges in development of smartphone application are discussed in this Chapter. As server-client architecture is chosen for our project, server platforms, client software and the communication between server and client are important for the system integrity. For developers, abundant choices can be found in two camps, open source and commercial software. In our case, the major concerns in choosing development platforms can be prioritised as following:

1. Technical advantages and disadvantages 2. Compatibility to the existing geodata infrastructure in NCA 3. Scientific values in our learning process 4. Cost-benefit

We shall choose the state-of-the-art technologies based on the user demands and NCA’s existing spatial infrastructure. As a part of the MTM learning process, how much we can learn from the project shall also be weighted highly. Economy has though low priority, because both Aalborg University and NCA own ESRI’s commercial licenses.

As discussed in Chapter 4.1, ESRI can technically offer a complete solution for the web server and map server. Besides, ArcGIS online opens a door to the brand new cloud hosting and computing world. We believe that will make GIS development more easily and popular among ordinary citizens. But for professional use or development of applications, different expensive extensions or accounts need to be purchased in parallel of ArcGIS. In open source world, we prefer the combination of PostGIS and GeoServer, as PostGIS is directly supported by GeoServer without any extension. Moreover, we would very like to practice the programming skills that are learned from the MTM courses.

60

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5 Prototype The chapter starts with short intro followed by the prototype requirements for the open source and ESRI environment. Both environments are structured by the geodesign model presented in Chapter 2.2. The underlying chapters are then presenting results on Content, System, and Interaction from the geodesign model, and the results of our development for Use Case 1. The chapter then ends with testing the prototypes on personas and two NCA-workers this is followed up by a summery.

As an initial practical-technological approach for selecting development platform, we have chosen to make a test of respectively open source and ESRI development platforms necessary to solve Use Case 1 in a technical way. Use Case 1 is the simplest, but most rated use case, and contains functionality letting the users make a registration of oil spill, by adding a photo and observation notes, and afterwards sending the information to NCA (see further details in Appendix 3).

The goal of this task is to test how easy or difficult it is to set up a technical environment adequate to solve Use Case 1. Based on the result of the test and the knowledge we get, hopefully we can get answer to which GI technology is the best for the application, and also can pinpoint some technical issues that will be important to take into account in our further work on development, and choice of platform for development with an ESRI or open source environment.

5.1 Prototype requirements To develop for Use Case 1 with the technology presented in Chapter 4 we set up the following system requirements.

The application should have at least those functionalities:

- work on all smartphone platforms, especially the most popular ones: iOS, and Android. - get access to camera functionality on the smartphone - get access to geolocation from the smartphone

In addition the user should get a confirmation on what he has performed and what he has not by 1) showing the picture taken, 2) confirming that the oils spill report has been sent

These functionalities will result in the needs of:

- a web server to interact with the users. - a domain for the web server - an apache software to communication from web server to database. - a database to store the responses. - a code library for menu, that support iOS and Android. - a coded website to bind it all together.

The coded website will require some scripting languishes, like HTML, PHP, CSS, JavaScript and so on. The combination of the website can be many, and the use of each scripting languishes can be for different purposes. To show a user what picture he or she have taken, will we need a “placeholder” example (Chapter 5.2.2, Source Code 2). As confirmation on the success of the performance, will we need to add some scripting that return a request, and gives the user a reply. The database will as well require some table structure for storing the coordinates, and observation information.

61

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.2 Open source based prototype In development project like these it is relevant to consider the possibilities of open source. Compared to many other projects in this sector, ours is very small and simple, and in this case open source offers what is needed to complete Use Case 1 plus adding a map site in extension. In general the four fundamental components of open source are the offers of freedoms (Stallman, 2010).

• The freedom to improve the program. • The freedom to study how the program works, and adapt it to any needs. • The freedom to redistribute copies. • The freedom to run the program for any purpose.

We started with surveying available open source technologies, where we surveyed the internet plus literature, e. g. Steininger and Hunter (2013), giving an overview of the open source GIS technologies. This was done by reading experts advice on forums like GitHub, Stackexchange and GIS Lounges. After having a basic knowledge, the individual component got chosen. From this point everything was pretty easy and quick, but the estimated time to develop a full application was not long enough. It was necessary to choose between a well functioning technical prototype with a design and working interface, and a technical prototype with no design, but with communication with a web server. The decision became a technical prototype, with a design and text that would look like the final application. This was chosen because the personas/test persons should have a good experience with using the application on the client side, and they would never see if the technology would function on the server side anyway.

By working with development of an open source environment, is explored the greatness of being able to test and work with technologies that requires no payments or royalties. While developing the prototype has it been easy to find support/trouble shooting on the internet, there is virtually no question regarding open source that have not got a profound answer. Open source development allows a maximum control of extensive configurability, and here by make a product with the exact needs. It has been easy to launch and it have required a minimum of hard coding in the technical prototype.

The objective for developing the prototype is that citizens must participate more in major oil spill situations. This is illustrated as the value in the geodesign model which has come to a result in Figure 30. It shows in a simple way, what the

Figure 30: Geodesign model for Open Source.

62

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

open source model contains to make the product fulfil the value from the problem statement.

The tree middle boxes will be described more in detail in Chapter 5.2.1 Content, Chapter 5.2.2 System, and Chapter 5.2.3 Interaction, because the three elements represent the method to get from the value to the final product/prototype.

5.2.1 Content - Open source prototype

In the open source development of the technical prototype, we have in the content tried to fulfil the mock-up wishes from the personas. This has as resulted in a little more complexity in the prototype and some extra work on the design. The framework is separated in three parts, a header, content and footer as in Figure 31.

There is added:

• NCA design has been added. • NCA logo has been added. • A description/intro text about the application. • Added a map, to make the application more interesting.

In extension to this it is added:

• Panels to give the user a stronger interface. • A map to confirm the registration is added. • A possibility to call directly, to the right number. • Labelling to guide the user.

Application design - Visualization and cartography

The HTML5 based application is a selection of individual components where some are used for mapping engine and others for homepage framework styling. To design the application we used jQuery and lots of testing on what and how it communicates with the users.

To complete the user interface design for Figure 32 and Figure 33 we used following codes: • In footer and header/title panel we used: data-theme=”b” because it looks exactly like NCA’s

homepage and publications. The theme shows the blue header and footer, from jQuery library. • In the content panel we used the default data-theme. • For the footer/navigation panel we used as little text as possible and a logo to graphically

communicate with the user. Samples: data-icon="grid", data-icon="arrow-l", and data-icon="arrow-r". The icon’s is simple pictures from the jQuery library, which is CSS-styled to stay right over the text.

Figure 31: Three elements make the content (referring to the geodesign model)

63

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Step 1 Step 2 Step 3 Step 4

Figure 32: Visualization of open source content through Use Case 1

In addition to Use Case 1 is added a map (Figure33) to make the users see the geolocation of the report he/others have send, this confirm the position of the oil spill report. The map site contains a “refresh” button, so users can watch all the incoming inquiries, and alternative use them to assist the environmental groups and organisations. There is also added a “back” button, which will bring the user back to the starting point.

Open source - Colours and contrast

The colours are representing NCA in the header and footer, where we use the contrast in the content sector, to separate the sectors from each other. This balance the application in a way, where the users can commit to the design, and easy navigate around.

Open source - Background map

In open source WebGIS can be built into the application, either as a web map service or as an API. The primary thing is therefore so see what serves the product users best, since NCA have brought all important maps in this case, will we have every map available. In the application we chosen to use Open Street Map, because it is a map people can commit to, and easy navigate around in. Open Street Map is useful between countries and it can be accessed by almost any given mobile platform. (www.openstreetmap.org, 04-06-2013).

Figure 33: Content of the map page

64

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.2.2 System - Open source prototype

In the open-source development for the application, we used HTML5 to make the client HTML-pages, that can visualize the process for the personas for a given use case. Use Case 1 requires communication with a database where the WebGIS send registrations to the database, and to style and map we need some coding using different libraries to complete. The database commutation was skipped to make the design of the user interface better. Agile method is used in the development to make it easy to get fast pieces of working code, there afterwards was taken into numerous iterations or work cycles, where the developing additional functionalities (modules) to the final prototype. In Figure34 is illustrated the open source modules there have been put into the agile development process.

To create the menu framework could not use OpenLayers or Leaflet, because they only supports map buttons etc. but no menus, they must be constructed through 3rd party frameworks like:

• jQuery Mobile • ExtJs • Sencha Touch

In our prototype we used jQuery Mobile, since it is a unified HTML5-based user interface system for all popular mobile device platforms. jQuery is built on the rock-solid jQuery and jQuery UI foundation; hence all parts of the code are tested and very well documented.

There are many ways to add a map to the application with mapping engines such as OpenLayers Mobile, Leaflet JS and Google Maps.

In this prototype we have used Leaflet JS, which is a modern open-source JavaScript library for mobile-friendly interactive maps. It is a lightweight build (Fuglsang, 2013), which makes it ideal for mobile data connections in the later development process. This results in two lightweight libraries, with a very good mobile performance. This is very easy to work with and very customizable with minimum knowledge in coding. Leaflet code structure taken raw from its source, will return the map when the HTML-file calls for “div”-element on the variable “map”. There are two JavaScript functions which “map.on” will load depending on location returned or not (Source Code 1).

Figure 34: Agile method for Open Source development. Scaled version Chapter 2.1

65

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

To add camera functionality we added a fieldset from jQuery (Source Code 2).

Source Code 2: Camera functionality code

The pictures geolocation is a must for the success of the project, and by using the JavaScript (Source Code 3), we take the current location, which can be stored in the database.

5.2.3 Interaction - Open source prototype

The user’s interaction from the geodesign model to Use Case 1, is very simple and doesn’t require many extra click or decisions from the user.

Source Code 1: Raw Open Source code (www.leafletjs.com, 20-05-2013)

Source Code 3: Script for getting latitude and longitude

66

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Interaction requirements from Use Case 1 are handled in our open source development as following:

1) The user starts the PP-GIS application! 1. Go to the domain www.k-verup.dk/MTM/, and the web-app should load.

2) User takes a photo. 1. The user clicks on button ”Report oil spill” 2. The user clicks on ”Registry a picture please”, and the photo will be added.

3) The user adds a note to the picture 1. The user simply clicks in the text field, which is pretexted to help the user.

4) The user chooses category of message (1 = oil spill observed at site, 2 = oil spilled birds or sea mammals observed)

1. Every option is added by using radio buttons.

5) The user enter contact details 1. This is skipped because the web automatically gets the information from the

smartphone (Source code not needed for the use-case visualisation).

6) The user sends the oil spill report 1. The user simply clicks on the “Send” button.

A flow model on how the users can interact with the application is visualized in Figure35. Flow directions are depending on the choices taken in the interaction.

Figure 35: Flowchart of open source product

67

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.3 ESRI-based prototype To solve the Use Case 1 with ESRI-technology, we decided to look closer into the capabilities of the ArcGIS Online environment. ArcGIS Online is ESRI’s cloud-based system for creating, hosting and sharing data, maps, applications and services. ArcGIS Online is one of the newest products from ESRI, and has during the past years been a product of great attention and promotion from ESRI, which is supported by this statement from ESRI’s founder and President Jack Dangermond (www.esri.com, 04-06-2013).

"ArcGIS Online is a new cloud-based mapping system for organisations that is essentially changing how GIS managers, as well as IT managers, think about mapping and GIS. ArcGIS Online works with all types of data and is built on a powerful enterprise mapping platform that lets users simply manage their geospatial content, such as data, maps, images, applications, and other geographic information."

With that, and a general knowledge of the product established through our technology review as a backdrop, we considered that it would be sensible to use some time testing out the capabilities of the product as part of the work on the prototype.

The further study of the capabilities of ArcGIS Online identified that the system offer capabilities to establish hosted feature services that can be used in ESRI’s standard smartphone applications and applications which are available for setup within the ArcGIS Online environment. We therefore decided to test out the totality of the systems capability, but inside the context of solving Use Case 1. This means that we have tested out the possibility for establishment of a dataset in a database to contain the registrations, to setting up a service on this, as well as application set-up so that the service can be consumed in a client that use the specific application.

As problem statement for developing the prototype, we used the same statements as we did for the Open Source development:

• The citizens must participate more in major oil spill situations.

This is illustrated as the value in the geodesign model which has come to a result in Figure36. It shows in a simple way, what the ESRI ArcGIS Online model contains to make the product fulfil the value from the problem statement.

While we in the Open Source development have used various components as HTML5, CSS, JavaScript, etc., we have for the ESRI case used an application template in the ArcGIS Online as the basis for system. Because of the predefined functions in the ESRI standard applications, we chose to adjust the models content box in accordance to that.

Interactions are, as for the Open Source, kept with the same text, just to fulfil and describe the whole model in a short way. The three components; content, system and interaction is described with more details in the next chapters.

Figure 36: Geodesign model for the prototype using ESRI ArcGIS Online capabilities

68

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.3.1 Content – ESRI prototype

In the ESRI ArcGIS Online development of the technical prototype, we have in the content tried to fulfil the mock-up wishes from the personas by choosing the most appropriate application template and set-up of the feature service. However, because of the predefined functions and elements in the standard application and limited time to test out the possibilities to change/simplify the elements, the result gave a quit more complex content than the indicated mock-up wishes from the personas. This is shown clearly in the Figure37 below, where application contents is displayed for every step the user will see.

Step 1 Step 2 Step 3 Step 4

Step 5 Step 6 Step 7 Step 8

Step 9 Step 10 Step 11 Step 12

Figure 37: Visualization of ESRI’s content through Use Case 1

69

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Application design - Visualization and cartography

The user interface and design can be tuned in some way regarding the setup of the feature service in ArcGIS desktop (symbolization of the features, predefined values, scale settings and so on), and after the feature service is published to ArcGIS Online through the further set up of a web map application (templates with some choices regarding colour setting and toolbar options). The illustration below shows how the user interface is when the application is used in ESRI’s standard App for iPhone.

ESRI - Colours and contrast

The process regarding set up of a web map application for using the feature service provide limited opportunities for changing the already established regime for colour and contrast. The web map application described in Chapter 5.3.2 about the System was, however set up with a blue header (which is one of few tuning-capabilities within the ArcGIS Online interface), but this header is not visible when the application is used in ESRI standard App for iPhone. When using such applications in ESRI’s standard app, the origin design of the application is therefore changed. This obviously gives some challenges regarding the predictability for the person who set up and design the application.

ESRI - Background map

ESRI provides several types of standard background maps shown in Figure38, and these are hosted as a map services. These maps have good cartography and are very responsive. The detail level is varying, but probably good enough for several types of tasks. Open Street Map is one of the standard background charts (and probably the most detailed), and was used as background map in the web map application.

Figure 38: Standard background map provided by ESRI in ArcGIS Online

In addition to standard background maps, ArcGIS Online also provide the possibility to add OGC services as WMS and WMTS. These can then being embedded in WEB Map application as a set of useful thematic data. The application was not set up with such services, but it was tested. The application consumed the WMS, but the response of the service was quite poor. Trying to consume several WMTS (open services from The

70

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Norwegian Mapping Authority) did not give any response. It seems that ArcGIS Online does not have full support for WMTS yet.

5.3.2 System – ESRI prototype

ArcGIS Online, with the licensing level “for organisations” (Aalborg university license) was used to host the feature service which was set up and published from ArcGIS Desktop’s ArcMAP application. The basis for the feature service was an ESRI file geodatabase. After publishing the feature service to ArcGIS Online, the most appropriate of the web map applications templates was chosen to contain the feature service. Both the feature service and the chosen web map application was then shared, so everyone could reach it with either the ESRI standard App for smarphones (tested with the app for iPhone) or via the standard web map application which can be used directly in a browser. The application can be tested here: http://aau.maps.arcgis.com/apps/Edit/index.html?appid=25d95050cdda46479e3198aee3eaaafb

When we take a deeper look into the source code of the template which is used as basis for the application, is it possible to see it is made of HTML site, which have been added some CSS and JavaScript. The template theme is called “Claro” (Source Code 4), and the most of the code is added in the header as references and the HTML code is only containing the “body class” call for “Claro” theme (Source Code 5).

Source Code 4: CSS call for the theme

Source Code 5: The whole HTML body section

In the HTML header is a configurable Java-code added to give the application owner a chance to change some of the colors and so on. However, the applications which are set up from the available templates can be tuned and customized using the ArcGIS API for JavaScript. Customized code can then be uploaded and saved in ArcGIS Online as a custom web map application. Furthermore, the standard ESRI App (e.g. for iPhones) could be customized with the ESRI’s SDK (available for iOS, Androide and Windows Phone) (Rosso, Bartley & Menon, 2012). Some further technical testing of the capabilities of this was not tried out because of the limited time we had available for the prototype development. During the test and development period, however, we got god knowledge of the capabilities within the standard framework of ArcGIS Online.

71

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.3.3 Interaction – ESRI prototype

Use of ESRI Standard App includes downloading it to your phone / tablet before you can use applications within it. The process includes several steps, visualized in Figure39 on the right side.

First, you start your application downloader, e.g. App Store, then searching ESRI. In the result list, you choose the App “ESRI ArcGIS” and press the install button. The ESRI App is then installed on your smartphone. The ESRI standard application is now ready to use for searching up the ArcGIS Online hosted web map application, and the further user interaction can be summarized as follows:

1) The user starts the PP-GIS application 1. The user download the ESRI standard app for smartphone e.g.

to use on an iPhone from iTunes: https://itunes.apple.com/us/app/arcgis/id379687930?mt=8

2. The user search for “oil spill”, get search result and open the map application “Public oilspill Reporting”.

2) User takes a photo. 1. The user click on the icon “Kartverktøy” 2. The user click on button “Innhent” 3. The user click on “Please report oil spill” 4. The user click on the icon “Vedlegg” 5. The user click on the button “Legg til” 6. The user click the button “Ta foto eller video” and takes a photo 7. The photo is added

3) User adds a note to the picture 1. The user fill inn notes in the predefined fields

4) User chooses category of message (1 = oil spill observed at site, 2 = oil spilled birds or sea mammals observed)

1. User choose one of the predefined values

5) User enter contact details 1. User fill inn notes in the predefined fields

6) User sends the oil spill report 1. User adds a point in the chart either by use of the smartphone GPS or by clicking in the chart.

User clicks “Godta” and the registration is posted to the hosted service in ArcGIS Online. The flow model below (Figure40), visualize the user-interaction with the application.

Figure 39: Flowchart for installing ArcGIS

72

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

Figure40: Flow model visualizing the user interaction when the Use Case 1’ prototype is used on ESRI’s standard App for smartphones (iOS)

5.4 Testing prototypes on personas Once again the personas are taken in use, by putting ourselves into their places and try test the 2 prototypes. There have been used following questions, with focus on usability principles like learnability, effectiveness and accommodation. Those principles are taken into a personas/citizen’s mindset, and thereby the feedback is returned (Benyon, 2010):

1. Have it been improved compared to the mock-up? 2. Have the design been improved? 3. What do you think about the process flow in the application? 4. Other think we should think of?

73

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The feedback from the personas is placed in Table 13, where it is possible to compare the feedback on the open source with the ESRI solution.

Table 13: Personas feedback

Point for comments

Open source prototype ESRI based prototype

1. Have it bin improved compared to the mock-up?

Kari: Definitively!

Espen: Very much!

Benny: I think it’s the same, but it can do more things so it is also more advanced.

Laila: Yes.

Kari: Very much, but I don’t know what all the professionals GIS-tools are doing in the application.

Espen: Well, in some ways, but I will have to put some time into learning this application, it feels like you sometimes have to know what to do, to move on.

Benny: Definitively not an improvement.

Laila: Yes.

2. Have the design been improved?

Kari: The design has really improved and I think NCA will like it.

Espen: I really like the classic design, but the add photograph button is way too hidden.

Benny: The design is improved.

Laila: I see you have added, more details since the mock-up, and that was just what I wanted.

Kari: I still miss the NCA look, in this design.

Espen: The design is fine, but I don’t think my camping guests would like to have it all controlled through a map.

Benny: The design is improved; I really didn’t like the grey in the mock-up.

Laila: The design is fine, but where are the details for a given introduction text?

3. What do you think about the process flow.

Kari: The process flow is still simple and in many ways similar to the mock-up.

Espen: The buttons are big, and the flow is simple.

Benny: Well, as I said in question 1, it got better but also more advanced, my advice is: If you want to reach old people as user for the application, then don’t make it more advanced than it is now, for technology like Google where everything make itself.

Laila: Tell me when its ready and I will for sure help distributing it.

Kari: I think this is good for people, like me which uses the internet and smartphone’s a lot.

Espen: I have a hard time placing the needle at the right place in the map, therefore added more than there was really needed. I would like a more simple flow, where all unnecessary buttons was removed.

Benny: Is not a application for me, couldn’t even install it to begin with, and after that I got totally lost in buttons and new pages...

Laila: Hmm, the application confuses me at some point, but I think the environment people can handle it anyway, as long as we can save the environment, are we willing to do a lot.

4. Other things we should think of?

Kari: I the final release I think you should find a better middle way between the 2 prototypes, they both have something to offer.

Espen: I think you guys should go with the open source. I have a better feeling here, but absolute no technical insight.

Benny: Well well well boys, think of the users, and if you keep it simple I would likely take my smartphone with me out in the nature when I photograph and always know that I will have the application nearby. Its good with functionality so we can follow the oil spill. That is what I call making a product interesting.

Laila: Well, don’t know anything about the technology, but I do like the open source better.

The feedback will be brought into the discussion in Chapter 6.3, and be used as a quality proof of which technology strategy we will have further on.

74

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.5 Testing prototypes on professional users As mentioned in the methods chapter (Chapter 3.5) we made only one personas representing NCA with the hope to get access real users within NCA’s organisation. During an oil spill situation exercise 28.-29.5.2013 we got S. Berger and K. Aasebø to test the two prototypes see Figure41.

The applications were made available on their own smartphones, and we observed how they used it without interfering with their experience. Since they had not seen the mock-up from Chapter 3.7, comment point no. 1 from personas test was not relevant.

Figure41: NCA-workers testing the prototypes

For later tests we should also try functionality in outdoor environment, to make it even more realistic. The feedback from S. Berger and K. Aasebø is added in Table 14.

Table 14: User responses from two of NCA-workers, with experience from oil spill operations

Point for comments Open source prototype ESRI based prototype

1. Compared to mock-up

- -

2. Comments on design

S. Berger: “Good design. Keep the clean design with few icons, and choices. Better than the design on the Deepwater Horizon app ‘BP Oil Spill tracker’, where more choices are presented in the user interface.”

K. Aasebø: “Good design”

S. Berger: “OK, but much more clicking than the open source app.“

K. Aasebø: “I am familiar with the ESRI look, I would prefer a NCA makeover”

3. Responses on the process flow

S. Berger: “I found the way easily”

K. Aasebø: “Starting up to left is a good way”

S. Berger: “I managed to complete the process OK because of experience from a parallel Deepwater Horizon App, but this is more clicking than necessary”

K. Aasebø: “Had hard time to find the way through this app, and had to get much assistance to complete the process”

4. Other things Both: Immediate response was that they wanted to see their oil spill reports on the map!

75

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

5.6 Summary on prototype testing We have now tested open source and ArcGIS Online technologies on mobile app development, which gives the foundation for further discussion in Chapter 6. When developing and testing on open source, we found a flexible framework where everything is up to the skills of the programmer. Everything is possible and every needed code, is on the internet, and can be added by smaller configurations. We can therefore conclude that open source is the freedom to create anything you want, only limited by the programming skills of the developers and the time available.

After testing the ArcGIS Online environment, we can conclude that this is a powerful framework to relatively easy set up a feature service for data registration and further use ESRI’s standard applications for smartphone’s to reach the citizens. However, the standard applications and its functionality, does not provide the best usability. To develop an application as user-friendly as possible, we must within the ESRI framework expect significant programming and design work. The ESRI standard application also has a lot more capabilities then necessary to solve the registration work. Figure42 below illustrates the whole capabilities of ESRI standard application (whole model) part (marked with the red boundary) used in this project. All those unnecessary (to solve this specific task) capabilities can easily lead to confusion for the user. This was made clear when the application was tested on personas and real people at NCA emergency department (Chapter 5.5).

Figure 42: ESRI standard App’s full capabilities (whole model) and the used part of it (within the red boundary), and in a scaled version in Appendix 7

76

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

6 Discussion In this chapter we discuss the key findings related to our three major questions presented in our problem statement (chapter 1.3). We start with our user involvement in the development process (chapter 6.1) which has been an important task for us and a key element for the work of this project. Then, in chapter 6.2, we take a closer look into the organisational challenges that we think will occur if an implementation of the Smartphone PPGIS in NCA is realized. Finally in chapter 6.3, we discuss the findings from our technology review and prototyping process.

6.1 Handling the user requirements To assure a proper system development it is of major importance that the user requirements are brought well into the process of development. So how should we involve users and user requirements during a flexible and agile process to push the development in the right direction?

The general requirement of information exchange between oil spill actors and citizens was documented in our previous survey and showed that a Smartphone PPGIS for oil spill information exchange should be developed to facilitate a 2-way information flow (Verup et al., 2013). Based on the identified user requirements, we have now designed seven Use Cases to conceptualize the user requirements. We started with an empty Use Case-template and ran through all the identified user requirements jointly and sequentially wrote down the different elements, which thus resulted in seven different use cases. This workflow, combined with the stringent way of development (describing goal, actors, basic course of events and so on) is clearly a very effective and systematic way of conceptualizing user requirements. We had a lot of discussion about the different use cases, however, these discussions were not related to establishment of common understanding (which can be a challenge in the way we work with this report – four people, two languages and on different locations) but rather in relation to simplify and tuning the use cases. Based on this good process, we now have established a quality assured basis for the system development of the Smartphone PPGIS. To assure the further development goes in the right direction, we have developed fictitious Personas, which shall be used to test the different versions developed. The alternative – involving a real group of citizens representing the variation among citizen, would require to large resources in performing tests. The main challenge when developing Personas is to establish a reasonable level of the variation in stakeholder type. Six categories of affected citizens were set up as a result of our previous survey. These six were then reduced to three Personas, also covering the main different stakeholder types: definitive, expectant and latent stakeholders. To represent NCA, we landed on one Persona. We considered this to be sufficient because we have a crisp identification of the NCA stakeholder type, which should represent the Operation-unit and the Planning and Environment unit (Figure 5). In addition, we also planned to involve real persons from this group in the further testing process.

The spread in the level of expertise on the use of smartphones among our Personas was an important backdrop to our development process. Even though a majority of the citizens today have a smartphone, the experience with it will differ very much. Limited experience with functionality that goes beyond the smartphone’s basic functionality (calling, SMS, surfing the internet etc.) is clearly an issue that should be taken into account. The user interface of the final Smartphone application should therefore be as simple and intuitive as possible. Developing a first mock-up based on the most prioritized Use Case, and then presenting this to the established Personas gave us useful feedback. The mock-up gave us good feedback

77

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

directly because it transformed the use case to a conceptual user interface. This, in combination with the feedback from the Personas, was particularly helpful in the first development process. The outcome of this helped us tuning the basic Use Case and the mock-up.

The development process we have performed has a strong agile profile, as we presented mock-up versions established after short time of development to our Personas, got feedback, and made adjustments accordingly. However, the Use Case in itself is a quite more systematic approach, but the combination of these methods – the agile process test-driven nature, and the systematic structure of the Use Case, however, seems to be a very suitable approach for this kind of system development. This is supported by the literature, which also notes that it can be a challenge to find the right balance between the agile process and the more structured approach when using the Use Case method (e.g. Lindstrøm & Malmsten, 2008).

6.2 Organisational challenges Our major question number two is what challenges we should expect for an implementation of the Smartphone PPGIS within the NCA’s organisation.

NCA’s oil spill emergency organisation is very operative oriented. They have a lot of instructions and procedure regulating their operations, training and preparedness planning. They utilize GIS and geodata extensively in training and real oil spill response situations. The review of the NCA’s contingency plan and associated instructions and procedures, however shows that NCA at present do not have a distinct written documentation of how GIS and geodata should be used in activities regarding their oil spill emergency response. The use of such solutions is admittedly described, but just in a general overall context.

The use of GIS and geodata in NCA is seen as a crucial tool for achieving a common geographical situation picture. The lack of procedures and instructions for using these systems may therefore seem somewhat strange. However, it is only in the last years that GIS has become an important support tool for the operative part of the emergency work In NCA. The “Full City” accident in 2009 marked the beginning of the use of this, and the GIS technology is in full development and further implementation in the organisation. Such tools has, however been used earlier, but then in a context of preparedness analyses, before accidents have happened. NCA’s emergency organisation is thus a relatively young organisation with respect to the use of GIS as a strategic operative support tool, which is probably the main reason why the framework for the use of these systems are not yet fully developed.

Another project, “Map based emergency response solution”, which is currently running in the NCA and where the goal is to develop a uniform WEB GIS solution to support the oil spill emergency response, will raise the use of such type of decision support system in NCA on a higher level. The new system shall also be integrated with NCA’s newly implemented “CoastCIM”, which is a log-system for all events that have a potential to be a pollution accident. These, in combination with the documented need of a smartphone tool to increase the citizen-dialogue during oil spill, state the need for a better documentation of how these GIS-solutions, and the information they produce, should be used and handled. This need is also supported by key staff at the NCA’s emergency department (Silje Berger, pers. comm.).

Based on the developed Use Cases, we documented a need for NCA to validate the oil spill reports with a combination of automatic and manual routines. The most important aspect of the validation is to ensure proper use of the citizens-reports during NCA’s oil spill emergency operations. Secondly, the validation

78

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

process should also include a feedback from NCA to the reporters. To ensure a high level of quality, and a uniform management of the reported data, it will therefore be important to develop proper documentation of this, and see this as a necessary part of the system implementation within NCA.

The need to better document how GIS, as generic support tool, shall be used in NCA’s emergency organisation are therefore present. This need is related to the overall use, not only to the PPGIS application we design during our work in this report. Our review of existing procedures showed a potential that GIS can be included in a large number of these. The use of GIS seems to be suitable and may provide increased value in wide range - from the initial procedure that describe the information flow process regarding decision if an accident should become a state led action or not, through the procedures that supports the operative field work, to the procedures that is made to support the intern and extern communication work, it seems to be a potential for the use of appropriate GIS components. Based on this fact, and the significant present investment in the GIS area within NCA, it therefore suggests that NCA will profit to be significantly more spatial aware in their future work with the emergency related procedures and instructions. It is not within the scope of this report to go into detail on all relevant procedures and instructions with respect to all GIS use within the NCA emergency work. The aim is, however, to identify the organisational challenges that we think will occur if an implementation of the Smartphone PPGIS in NCA is realized. An implementation of the PPGIS application will, as shown earlier in this chapter, introduce both a new system and a new way of working to process the relevant information items. It seems that the use of such type of application should be implemented within the organisation unit “Operation” (see Figure 5). NCA is working on a revision of their contingency plan included related procedures and instructions. The instructions guide the internal information flow between the three central operation units, and the relevant on-scene commanders, which should be updated to include the use of the Smartphone PPGIS for information exchange.

Since the PPGIS application has such a strong citizen focus, and that a successful use of it depends on how the citizens are getting informed about its existence, it is also nearby to review the procedures and instructions for the role “Function Leader Communication”, where this roles task are further defined in the instruction “Operation Plan Communication”. Another important task to ensure proper use of the PPGIS application is the technical management. Developing an appropriate instruction for the technical management of the system, harmonized with the instructions for the “Operation unit” and “Function Leader Communication” is probably the right way to go.

These three roles - Operation unit, Function Leader Communication and the Operation Leader’s “ICT-staff” are interdependent for the system to work well and provide maximum utility, and it is therefore natural to see these roles in the common when the organisational framework for the PPGIS application shall be prepared.

Regarding the pure technical implementation of the PPGIS application within the framework of NCA’s existing SDI, we have not been able to pinpoint any special technical challenges. NCA’s SDI consists of full infrastructure from both Open Source and ESRI, and both infrastructures are fully capable of handling the PPGIS application. NCA implemented the Open Source infrastructure in 2010/2011 as their primary geodata management system. Besides Open Source components like PostgreSQL PostGIS, Geoserver, Open Layer, GeoNetwork etc., the system also use FME and a custom made ArcGIS plug-in as key components. This geodata management system is therefore, through extensive use of OGC-compatible system components and high support to a lot of different data formats through FME, well prepared for further developing. The same applies regarding the ESRI Infrastructure, which was implemented as a fundament for NCA’s new

79

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

nautical management system in 2012. ESRI offers a lot of capabilities to support an implementation of the PPGIS Application. With the ESRI infrastructure, a lot more is already prepared (as our chapter 5 shows) regarding setting up a basic functional solution. But in respect to the pure technical aspects, our technology review has not led to knowledge that favours one infrastructure for another regarding organisational issues. Regarding capabilities of cross-country functionality, which is an important issue that we shall taking into account in the system development process, we also here could not identify some significant differences between the Open Source and the ESRI infrastructure. Both infrastructures have good OGC-compatibility and support of W3C-standards, which is considered to be the most important factors regulating the technical capabilities of spatial data exchange between different GIS systems (www.gsdidocs.org, 26-05-2013).

6.3 Technology review and prototyping Which GI technologies are best to choose for our further development of the PPGIS application? This is one of our major questions we want to establish a well-founded answer on during this study. We have chosen to focus our technology review on respectively ESRI and Open Source because NCA has implemented a full SDI including components of both of these GIS environments. In addition to that, these environments represent a considerable part of the GIS systems and components used internationally. A choice between these or a combination of them shall be discussed in depth.

The term Open Source represents admittedly not a clear distinction between commercial products such as ESRI and so-called Open Source products. Open Source briefly means that the source code is freely available to use, modify and redistribute (www.opensource.org, 01.06.2013). There are however, smooth transitions in both environmental. For example, the NCA’s Open Source SDI primarily consists of a software package called Adaptive, which is a commercial product. Adaptive again, is primarily made up of Open Source components like PostgreSQL PostGIS, MapServer and Open Layers. ESRI in turn, moves step by step into the Open Source community by sharing code, code examples, SDK’s etc. at GitHub and on their own supporting sites. ESRI is also increasing their involvements in the open source community by participation in Open Source events and organisations. ESRI recently also stated the following, which clearly shows that ESRI takes into account the rise of Open Source GIS (www.esri.com, 01-06-2013):

“Deciding between open source and ArcGIS is not an either/or question. Esri encourages users to choose a hybrid model, a combination of open source and closed source technology, based on their needs.”

This statement, from one of the biggest GIS-development company in the world, makes us quite confident that we are doing our assessments within the right technologies. Achieved knowledge of both chapter 4 (GI technology for smartphones) and chapter 5 (Prototype) is used as the basis for the following discussion. The discussion regarding the prototype is built up in accordance to the geodesign model's three main components: content, system and interaction.

6.3.1 Technology review

We early identified that the technology review should concentrate on client-server architecture as PPGIS application is concerned. This architecture includes several components necessary to establish a complete environment for development and operation of a PPGIS application for use on smartphones.

80

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

The basis for WebGIS is the web server. We identified the three most popular web servers to be Apache, IIS and Nginx, with the first two as the most appropriate. Apache server has a clear majority with over 50% of the web servers worldwide, it has a lot of extensions available which enhance Apache’s functionalities and improve its compatibilities with different operative system, server side scripting language and database platform. Apache, with its high popularity and functionality is therefore thought to be a safe choice, if we just consider the technical capabilities. However, since IIS is a standard part of the MS Windows Server Software, only works on Windows platform and fully supports .NET framework, it is a clear choice in organisations that has standardized on Microsoft’s framework. NCA has standardized on Windows platforms and .NET and has therefore considerable experience with this framework. In recent years increased emphasis on GIS in the NCA, including extensive use of Open Source components in their SDI, has led to a more open attitude to potentially deviate from this standardization in terms of infrastructure behind GIS solutions (Rune Oksnes, pers. comm.). But it is far from outcompeting the Microsoft’s domination. Emphasizing the NCA's existing IT infrastructure, standardization and expertise, IIS will thus be the most appropriate choice.

The web map servers extend the interoperability of GIS systems utilizing the web, and there are many web map server software to choose from. A primary distinction is again open source and commercial software. Developers have mainly been following one or the other way. A major choice of technology for our PPGIS application is between ESRI’s ArcGIS Server and the open source products such as MapServer and GeoServer, because NCA has all of these as part of their SDI. MapServer and GeoServer have very good support of OGC standards. MapServer is stronger at performance, scalability and stability, while GeoServer is easier to extend, and follows the various web mapping standards more closely.

ESRI ArcGIS Server represents the commercial web map server, and is a key component in a full ESRI infrastructure and offers significantly more functionality than the Open Source Web map servers. While MapServer and GeoServer primarily offers rich support to OGC-standards, ArcGIS Server on its side also offers capabilities to share GIS resources as maps, feature services, databases and toolsets, and make these available for interaction with different type of clients using web- and industry standards like REST (Representational State Transfer), SOAP (Simple Object Access Protocol) and OGC standards. The support of OGC standards has until recently not been as good for ArcGIS Server as it is for GeoServer and MapServer. The release of ArcGIS Server 10.1 however, has led to significantly better support, and this version is also supporting standards like WFS-T and WPS. WFS-T may be interesting in our case with a Smartphone PPGIS because this OGC standard allows for vendor independent data access and editing in the context of service-oriented architecture, which is considered to be important, also regarding capabilities of cross-country functionality. Therefore, we could not identify some significant differences between the Open Source and the ESRI infrastructure in support of OGC-standards.

The three web map servers all offer web-based interface for administration. ArcGIS Server also provides the opportunity to use the desktop tools ArcCatalog and ArcMap for setup, management and publishing services, which is advantageous for users because they are offered a pleasant and familiar user interface. However, we do not consider this to be a significant factor regarding our choice of web map server.

In addition to ArcGIS Server, ESRI also provide the product ArcGIS Online. ArcGIS online is a lightweight server with some of the capabilities we know from ArcGIS Server. Besides, it also provides the capabilities to host services in ESRI’s secure cloud and setting up web map applications within predefined templates, which can be used directly in a browser or in ESRI’s standard application for smartphones. This capability

81

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

was tested in conjunction with our prototyping of Use Case 1 (Chapter 5). The testing showed that setting up a feature service in ArcGIS Desktop 10.1 (ArcMap) based on a file geodatabase, and further publishing it to ArcGIS Online, established a good basis. The further set up of the web map application, based on the most appropriate template and the hosted feature service, established a fully functional application which provide capabilities to capture, edit and transfer data between the client and the hosted database. ArcGIS Online’s capabilities have, however, some limitations in relations to the control level of access to the hosted services (not possible to control edit access to services that are published), there is no versioning capabilities as we know from ArcGIS Server and the web map templates user interface is to generic to offer a intuitive enough user interface. Versioning capabilities may be a proper way to handle validation issues and to be able to track changes in the database. In an ESRI environment, this is not possible without ArcGIS Server. ArcGIS Online, as the capabilities are today, is not considered to be an appropriate system to proceed with as a replacement for ArcGIS Server.

Regarding databases we are in our project facing different data size and data types, including spatial data. It is therefore important to choose a proper database with spatial enabled features. The major criteria are data operability and performance. Cost-benefit will be a secondary requirement in consideration. Our study shows that there are many open source or free database systems available and that they are tested with millions of applications. It also shows that the most prevalent of them have reached the enterprise level regarding performance. Choosing one of the most common and frequently tested free databases which also provide spatial functions is therefore a well-founded choice. SQL Server Express, PostgreSQL PostGIS and MySQL were identified as the most appropriate. PostgreSQL with PostGIS extension, however, points out as the most appropriate database system for handling spatial data. It has the absolutely largest support for spatial functions, web mapping toolkits and has no licensing limitations, which is the case for SQL Server Express. PostgreSQL also has a built in user-friendly management interface, which is stated to be a bit of lack with MySQL. MapServer, GeoServer (with extension) and ArcGIS Server all support the three above databases. If ArcGIS Server is used, the ArcSDE is applied in communication with the databases. This component leads to poorer performance than when data is stored in a spatial enabled database, like PostgreSQL with the PostGIS extension. How much this may have to say performance-wise for our project is difficult to quantify at this time. However, it is important to minimize loss of performance in all possible parts of a system.

Beyond the infrastructure that is necessary to handle dataflow and applications, one of our major challenges is to determine which technologies we should choose for developing the PPGIS application with its specified content. The client side of our PPGIS application refers primary to a smartphone, and we have through our study focused on the three major types of mobile apps: native apps, web apps and hybrid apps. All types have their advantages and disadvantages. Native apps are the most feature-rich, but also the most proprietary and platform dependent solution. Web apps profit on its cross-platform affinity and no app-store distribution limitations, but have important limitations, e.g. regarding access to the devices local file system. Hybrid app is between these, utilizing both cross-platform capabilities and local device functions.

Our PPGIS application shall be used by potentially all citizens that are influenced in oil spill situations – from a GIS specialist to any unqualified user. The importance of designing an intuitive and smooth interfaces adjusted to the user requirements is therefore of major importance. Platform independence is also considered to be desirable, so the PPGIS application can run on smartphones (and potentially other

82

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

devices) regardless their operating system. A development of a web app, which can utilize local device function and run in the browser, is therefore presumed to be the ideal solution. However, this has until recently been almost impossible to do. The last revision of the HTML standard (HTML5), however, probably facilitates the basic needs so that this actually can be done.

HTML5 brings new opportunities to the development of web apps by e.g. enabling playing multimedia files natively in the browser without plug-in and by providing several HTML5 API that can be used with JavaScript (enables e.g. functionalities as web storage, offline web applications and geolocation). The most interesting point of HTML5 is clearly this supply of programmatic features, which can help us to deal with many of the technical challenges (e.g. offline use and offline cache) we face in this project. HTML5 is therefore a basal fundament for further development of a web app which should contain the technical content, conceptualized from our findings from the user requirement process.

While HTML5 is the basic for development of a universal web app, both technology review and technical development of the open source prototype, showed us that the style sheet language, CSS is a powerful and well suited language to bring the application layout to a professional level. By using CSS, the presentation of the web app can be adapted to different types of devices, such as pc screens, mobile screens etc., which is considered to be an important attribute with a platform independent web app. CSS is not HTML itself but is compatible with any markup language. This structure separation of content (HTML) from presentation (CSS) allows centralized site updating of the app, which is a basic when developing web apps.

CSS is now released in version 3. CSS3 defines various features in separate modules, and the capabilities and features of these are defined by the CSS work group in W3C. This association provides confidence for that further development of this specification has operability and long-term development in focus, which is important to take into account for the choice of different technologies.

HTML, which is the main mark-up language for creating web pages, was used as the backbone for our Open Source prototype development. Leaflet was used for the web map with its GIS functionalities, and JQuery for designing the interface. Leaflet leans heavily on HTML5 and CSS3. CSS3 is used extensively in Leaflet, which is a JavaScript library for mobile-friendly maps. ESRI supports HTML5 developing through the ArcGIS API for JavaScript. Leaflet has greater attention to HTML5 and CSS3 than ESRI. This is probably due to that these technologies is considered to be a greater basis for Leaflet than it is for ESRI’s ArcGIS API for JavaScript. Leaflet is also quite leaner than the ArcGIS API for JavaScript. Leaflet consisting of just about 28 Kb of JavaScript code (www.leafletjs.com, 20-05-2013), while ArcGIS JavaScript API consisting of approximately 145 Kb (blog.davebouwman.com, 06-06-2013). This means that Leaflet is basically leaner and, since there is less JavaScript code running, more responsive. This is absolutely an advantage that will benefit the performance capabilities of a Smartphone PPGIS application, where bandwidth will often be a limitation. A disadvantage of CSS3 mentioned in the literature, relates to that CSS3 does not work consistently in all different browsers. This is a challenge we have to consider in the further work. However, CSS3 is undoubtedly an important component in the future development of web map applications, and increased browser compatibility will therefore be a part of the totality.

Our study shows that JavaScript is the backbone for both Leaflet and the ESRI ArcGIS API supporting HTML5 and CSS3. It also shows that JavaScript becomes the most commonly used in web browsers with the rise of HTML. This because HTML5 adds a lot of new features to the web pages, but many of them is unusable in

83

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

the absence of JavaScript. JavaScript is therefore definitely a scripting library that is essential for development of web map applications.

Besides the challenges we are facing regarding choice of the most proper development platform for the Smartphone application, we also have to take into account potential limitations that lies outside the control of the technical development environments. Such challenges are, through the work on this project, identified to be primarily related to hardware of mobile equipment and mobile network. 90% of the smartphones have both WiFi and at least 2G mobile networks. This is the fundament of how the wireless communication can be built up in our web app. To focus on performance capabilities in all component we use in the application and the underlying SDI, to ensure the most responsive application, is therefore of major significance. Performance capabilities also implies on another serious constraint for many mobile devices, namely battery capacity. The PPGIS application will cover web, network, GPS and photo taking. All elements that potentially have influence on the mobile devices battery capacity. Mobile network coverage is another constraint for smartphones, as most of the mobile apps totally or partly rely on the wireless communication. GPS navigation in a smartphone is also dependent on the mobile network communication. Mobile network coverage always has weak and eventually blind areas. These areas are unfortunately also present near the coast, where our Smartphone app shall be used. Offline cache facilities shall therefore be considered as an important part of the further development. Kjeldsen (Bent Gaardsvig Kjeldsen, pers. comm.) states that there already is developed some different variations of offline cache codes, and such samples were also found on forums like Github. National Danish projects like “Pilotproject Mobile Digital Forvaltning” also state the importance of offline cache capabilities in projects regarding mobile GIS (Miljøministeriet, 2012). The ability to learn from existing work regarding offline cache is therefore present.

Regarding location calculation, the most obvious is to use the GPS-unit included in the smartphone, which nearly all smartphones have inbuilt today. The location can be calculated using A-GPS, which both use satellites and base stations. This precision varies up to 30 meter, which is more than good enough for the identifying of the polluted areas that will be reported.

The above described potential challenges, compared with our review of different technical development platforms and components, does not change our approach to that a HTML5-based web app is the way to go for our further development. In addition to pure technical review, we also did some practical testing of the potential development components. The findings from these are discussed in the following chapter, to give further basis to our choice of GI technology.

84

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

6.3.2 Prototyping

Our goal for the prototyping was to test how easy or difficult it is to set up a technical environment with respectively Open Source and ESRI components, adequate to solve Use Case 1 (chapter 3.3). Given the short time we had available for the prototyping, we had to make an early choice in terms of where the effort should be focused. In terms of Open Source, we chose to concentrate on develop design and user interface rather than full technical development (not any connection to database). Regarding ESRI, we focus testing out the capabilities of ArcGIS Online, and then in a full scale development (user interface and connection to a database).

The identified prototype requirements from use case 1 indicated the following functionality:

The application should: • work on all Smartphone operative systems, especially the most popular ones: iOS and Android • get access to the smartphones camera function • get access to geolocation from the smartphone • give the user confirmation on what he had/had not performed by:

1. showing the picture taken 2. confirming that the oil spill report has been sent

As a framework of our discussion, we bring in the components from the geodesign model as we used presenting the prototype in chapter 5: value, content, system, interaction and product. A repetition of the meaning of the components is given here:

Value: refers to the specific success statements that is defined, and which wants to be reached in the process to the final product. When the transformation processes are successfully done, Value of our system design can be evaluated based on those success statements.

Content: is everything the user will be able to see on the client site. This includes all styling and design up-set, with frames, logo, themes, colours and contrast.

System: is what makes the application to do exactly what we want it to do. By this we mean the codes, platforms and libraries to make the motor run, and scripts that are important in the application, to fulfil the prototype requirements.

Interaction: Is like a user manual for the right way to interact with the product. Interaction can also be visualized in a flow model.

Product: refers to the prototype in this project. Users can use Product to realize their requirements.

Value In this case the value is: “The citizens must participate more in major oil spill situations”. Since the degree of success rate of this is connected to the feedback from the Personas and the test persons in NCA, this must be seen in close relation to the user experience feedback. The better the feedback is, the higher the success rate is.

Content In the open source development we experienced a high degree of flexibility in designing the content items. We used the Personas under the design phase. Based on the response from them, we added some more items, which quite easily were implemented with the tools we used.

85

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

In the ArcGIS Online development there were limited opportunities for changing the already established content regime which was based on the application template. Even though we were able to set up a full technical solution within the ArcGIS Online framework, the limited capabilities to change and tune the design, was prominent.

System In the open source development we tested Leaflet JavaScript to build the interactive map and the function as e.g. geolocation. HTML5 and JQuery Mobile were used to build the pages and buttons. We experienced that it was easy to find support/trouble shooting on the internet, and that it was no upcoming questions that did not find its answer. When developing and testing on Open Source, we found a flexible framework where everything is up to the skills of the programmer. However, we have through this project just got experience from the front-end development. Development necessary to full-fill the requirements from all Use Cases will certainly require more.

In the ESRI development we used ArcGIS Online as a basis for the development. In this environment we hosted the feature service which was set up in ArcGIS Desktop with the basis of a file geodatabase. The web map application that consumed the hosted feature service was also set up within ArcGIS Online by choosing one of several web map templates. The web map application was then shared, so everyone could reach it with either the ESRI standard App for Smartphones (tested with the app for iPhone) or via the standard web map application which can be used directly in a browser. We experienced that the ArcGIS Online environment was easy and intuitive to work with, but that it has limitations regarding capabilities of modifying the content elements in the set up of web map solution. However, the applications which are set up from the available templates can be tuned and customized using the ArcGIS API for JavaScript. Doing this, you can’t host this custom web map application in ArcGIS Online anymore - it must be hosted from another web server, which clearly is a drawback.

Interaction The user interaction of the two prototypes, which was developed to solve use case 1, has large differences. While the Open Source prototype was found easy and intuitive to use, the ESRI application was found much more complex. The ESRI standard App for Smartphones must first be downloaded from the AppStore before it can be used, which already then involves several interactions with the user. Then, the web map application must be searched up and activated on the smartphone before the user is ready to start the registration. The Open Source was ready to use, directly in the smartphone browser.

Product The products – the two prototypes, were quite different. The ESRI-based prototype was the only one which full-filled the Use Case 1’s requirements. But the usability was experienced as quite poor when the prototype was tested against the Personas and the personnel from the NCA. The Open Source prototype however, did not meet all the requirements from Use Case 1, but had a significantly better user interface. The feedback from the Personas and the NCA personnel went undoubtedly in favour of the Open Source prototype.

We have now discussed the key findings related to our three major questions presented in our problem statement (Chapter 1.3). Based on this, we draw the conclusions in the following chapter (Chapter 7).

86

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

7 Conclusion “With today’s technology, how can we best develop a Smartphone PPGIS for involving citizens after large oil spills, to contribute to a better oil spill emergency response and clean-up operations?”

This problem statement has been our guidance through the project. To achieve an answer to this we have during the project analysed three supplementary questions:

- How should we involve users and user requirements during a flexible and agile process to push the development in the right direction?

- How the existing procedures and routines are in NCA’s oil spill emergency response and what challenges should we expect for an implementation of the Smartphone PPGIS within NCA’s organisation, also including the requirement of cross country functionality.

- Which GI (Geographical Information) technologies are best to choose for our development of the required Smartphone PPGIS? Should we build on Open Source GIS, commercial GIS (commercial GIS here represented by ESRI software), or a combination?

The combination of Use Case’s, Personas and mock-up to conceptualize the user requirements of the Smartphone PPGIS application is found effective. The agile process’ test-driven nature and the systematic structure of the Use Case is undoubtedly a very suitable approach for this kind of system development. In further development, which will contain more technical development, we shall consider a more agile approach, where changes in user- and system requirements caused by test results continuously can be brought directly into the next loop of development.

Based on the developed Use Cases, we have documented that there is a need for NCA to validate the oil spill report. The most important aspect of the validation is to confirm and eventually classify the reports and to ensure proper use of the reports during NCA’s oil spill emergency operations. Secondly, the validation process should also include a feedback from NCA to the reporters. To ensure a high level of quality, and a uniform management of the reported data, it will therefore be important to develop proper documentation of needed routines, and see this as a necessary part of the system implementation within NCA. Validation routines shall be implemented within the organisation level “Operation”, but there are in total three units that should be considered to have a role in the management of the application, namely “Operation unit”, “Function Leader Communication” and the Operation Leader’s “ICT-staff”. There are not found any special technical challenges regarding technical implementation of the PPGIS application within the framework of NCA’s existing SDI. This also applies to cross country functionality.

This technology review and prototyping shows that the technical requirements of the Smartphone PPGIS application can and should be solved within the framework of a HTML5 based web app. Both Open Source and ESRI are capable as development platform, but the Open Source environment were found most suitable.

We will primarily use Leaflet, HTML5, CSS3 and JQuery Mobile in the further front end development. JavaScript will be used as scripting language. For database, we will choose PostgreSQL with PostGIS extension and Geoserver as map server. Web server will be IIS because NCA has standardized on Windows platform and also have great expertise on this web server. All these components establish the

87

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

technological basis for development of a cross-platform independent Smartphone PPGIS application for involving citizens after large oil spills. Proposals for further work are given in the next chapter (Chapter 8).

88

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

8 Proposals for further work The main purpose of this study has been to point out how we can develop a Smartphone PPGIS for involving citizens after large oil spills. . A realization of the application, based on the conceptualizations and result in this report is recommended.

Beyond testing the described concept, a realization also can demonstrate the potential for smartphone and mobile GIS that goes far beyond the specific purpose of this application. The combination of smartphone and GIS as a communication solution can be used in a number of other situations in the NCA and within other actors responsible for emergency operations. We have already had inputs from IUA’s suggesting a parallel tool for internal collection of oil spill reports. We believe that a full-fledged prototype can become a useful demonstrator of the use of modern GIS technology to meet the needs of communication and information exchange in many areas.

This gives us great motivation to address the challenge of developing a prototype, for the purpose of better oil spill clean-up operations, and giving high valued knowledge for later tasks.

A challenge in information gathering, particularly related to VGI, is the lack of quality control in the information collection (Lee & Kim, 2012). To facilitate automatic verification is therefore of high value. There are also several other interesting features that are relevant to examine in the development of a prototype for the seven described Use Cases:

- Automatic image recognition: Automated detection of oil spills at sea from satellite or aerial photography and satellite radar are today replacing labour-intensive manual review, like Kongsberg satellite’s Oil-Service which is included in NCA’s web map solution Kystinfo, and presented by Leifer (2012). Whether it is technically possible to develop automatic evaluation of the images collected by citizens with a Smartphone PPGIS can be an interesting topic.

- Cell clustering: Crowd sourcing can bring in a large amount of pictures and oil spill reports. To avoid information overload, clustering of oil spill reports, showing numbers of reports instead of a million points will give an improved user experience. Using colours to show which areas that have many oil spill reports can also provide a quick understanding of which locations should be given highest attention and priority in the oil spill clean-up operations.

- Offline cache: The application should work as well online as offline. This cause need of offline cache functionality to create the same functionality when the smartphone is offline as online, to store the data local on the client temporarily, and to do synchronisation of data when connection to mobile or WiFi networks comes available again.

- Distribution: To distribute a PPGIS application to all citizens is a major challenge, and possible solutions should be examined in parallel with an eventually prototype development. One step is to get the application presented in application libraries like Google Play, another to make a

We are also confident that the development of a Smartphone PPGIS for information exchange is of high value, as it is in line with many of the GIS-trends presented by UN Committee of Experts on Global Geospatial Information Management (UNGGIM, 2012). The GIS-technology for smartphones and handheld units also has developed much since Steiniger and Hunters review (2013), hence it is of high importance to

89

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

follow the development on technology during a coming period of development. We shall mainly be aware of new opportunities which appear, and eventually catch low hanging fruits. With this we mean both following GIS blogs and homepages of the open source GIS environments and catching up on scientific journals on GIS-issues.

90

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

9 Abbreviations ADO.NET ActiveX Data Objects NETwork

A-GPS Assisted Global Positioning System

API Application Programming Interface

App Application

ASP Application Service Provider

AUF Arbeidernes Ungdomsfylking

BMP BitMaP image file

GSD Berkeley Software Distribution

CAD Computer Aided Design

CCD Charge Coupled Device

CGI Common Gateway Interface

CMOS Complementary Metal Oxide Semicondutor

CNET Computer NETwork

CoastCIM Coast Crisis Information Management system

COSS Commercial Open Source Software

CPU Central Processing Unit

CSS Cascading Markup Language

C# C-Sharp

DBMS DataBase Management System

ED50 European Datum 1950

EDGE Enhanced Data for GMS Evolution

EPA Environmental Protection Agency

EUREF89 World Geodetic Terrestrial Reference System

1989

ESRI Environmental System Research Institute

EXIF EXchangeable Image file Format

FDO Feature Data Object

FM Frequency Modulation

FME Feature Manipulation Engine

FOSS Free and Open Source Software

GB GigaBytes

GDAL Geospatial Data Abstraction Library

GeoRSS Geographical Really Simple Syndication

GeoTIFF Geospatial Tagged Image File Format

GI Geographical Information

GIF Graphics Interchange Format

GIS Geographical Information System

GiST Generalized Search Tree

GML Geographic Markup Language

GNS Global Navigation System

GPL General Public License

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile communication

GvSig Generalitat valencieana Sistema d’informció

geográfica

HSEQ Health, Safety, Environment and Quality

HTML Hypertext Markup Language

HTTP Hyper Text Transfer protocol

IAA Incident Awareness and Assessment

ID Identity

IDC International Data Corporation

IIS Internet Information Server

INS Inertial Navigation System

iOS iPhone Operating System

IP Internet Protocol

ISO International Standards Organisation

IT Information Technology

IUA Interkommunale Utvalg for Akutt beredskap

JCT Joint Technical Committee

JDBC Java DataBase Connectivity

JPEG Joint Photographic Experts Group

JS JavaScript

JSP JavaScript Page

JTS Java Topology Suite

KB KiloByte

KML Keyhole Markup Language

KMZ Keyhole Markup language Zipped

L Legitimacy

LBS Location based Services

MB MegaByte

MBR Minimum Bounding Rectangle

91

Smartphone PPGIS for Oil Spill Information Exchange 3. Semester project, AAU

MM Multimedia

MS Microsoft

MSC Mobile Switching Center

MTM Master of Technology Management

NCA Norwegian Coastal Administration

NOK Norwegian Krone

P Power

PC Personal Computer

PHP Hypertext Preprocessor

PNG Portable Network Graphic

OGC Open Geospatial Consortium

OGR OpenGIS Simple Features Reference

Implementation

OMG Object Management Group

OS Operating system

PPGIS Public Participation Geographical Information

System

QR Quick Response

RCO Recovery Consistency Objective

RC0 Release Candidate 0

RDBMS Relational DataBase Management System

REST Representational State Transfer

RSS Really Simple Syndication

R-Tree Rectangle Tree

SDE Spatial Data Engine

SDK Software Development Kit

SDI Spatial Data Infrastructure

SFSQL Simple Feature Structured Query Language

SHP Shapefile

SLD Styled Layer Descriptor

SMS Short Message Service

SOAP Simple Object Access Protocol

SPIT Shapefile to PostGIS Import Tool

SQL Structured Query Language

SQL/MM Structured Query Language Multi Media

TC Technical Committee

TCP Transmission Control Protocol

TTFX Time To First Fix

U Urgency

uDig User-Friendly Desktop Internet Gis

UN United Nations

US United States

UML Unified Modelling Language

UMN University of Minnesota

UN-GGIM UN committee of experts on Global Geospatial

Information Management

UTM Universal Transversal Mercator

VGI Volunteered Geographic Information

WAMP Windows Apache MySQL PHP

WCS Web Coverage Service

WebGL Web Graphics Library

WFS Web Feature Service

WFS-T Transactional Web Feature Service

WGS84 World Geodetic System 1984

WiFi Wireless Fidelity

WKB Well-Known Binary

WKT Well-Known Text

WMS Web Map Service

WMTS Web Map Tile Service

WPS Web Processing Service

WS Web Service

WWF World Wildlife Fund for Nature

WWW World Wide Web

W3C World Wide Web Consortium

XAMPP X (“cross”-platform) Apache MySQL PHP Perl

XHTML Extensible Hyper Text Markup Language

XML Extensible Markup Language

2G Second Generation

2D 2 Dimensions

3G Third Generation

3D 3 Dimensions

4G Fourth Generation

.NET NETwork

92

Group 3, d. 06-06-2013 PPGIS in oil disaster 3. Semester project, AAU

10 References

Litterature: Ballatore, A., Tahir, A., McArdle, G., & Bertolotto, M. (2011), “A comparison of open source geospatial technologies for web mapping”, International Journal of Web Engineering and Technology, 6(4), 354–374

Benyon, D. (2010), ”Designing Interactive Systems – A comprehensive guide to HCI and interaction design”, Second Edition, Published by Pearson.

Benedict, K. K. (2005), “The Open Geospatial Consortium Web Map, Web Feature and Web Coverage Service Standards. an Overview”, Workshop Presented at the ESIP Federation Meeting, June 2005.

Booch, G.; Rumbaugh, J.; Jacobson, I. (2005), “The unified modeling language user guide”, Safari Tech Books Online

Boitsov, S.; Klungsøyr, J.; Dolva, H. (2013), “Experiences from oil spills at the Norwegian coast – a summary of environmental effects” IMR Report No. 23-2012

Boston GIS (2009), “Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6”

Breunig M.; Türker C.; Böhlen M. H., Dieker S.; Güting R. H., Jensen C. S.; Relly L.; Rigaux P.; Schek H.-J., Scholl M. (2003), “Spatio-temporal databases: The CHOROCHRONOS approach”, Chapter 7, Springer-Verlag, Heidelberg

Browning, T. R.; Fricke, E.; Negele, H. (2006). ”Key Concepts in Modeling Product Development Processes.” Systems Engineering

Brodersen, L. (2008), “Kommunikation med kort – Informationsdesign og visualisering”, 1. udgave, Nyt Teknisk Forlag

Carroll, A.; Heiser, G. (2010), “An Analysis of Power Consumption in a Smartphone”, Proceedings of the 2010 USENIX Annual Technical Conference. The USENIX Association, p. 271 - 284

Castledine, E.; Eftos, M.; Wheeler, M. (2011), “Build mobile websites and Apps for smart devices” 1st. ed. Sitepoint Pty Ltd

Cooper, (1999), “The inmates are running the asylum : why high-tech products drive us crazy and how to restore the sanity”. Sams, Indianapolis

Dallmann-Jones, A. and the Black River Group (1994), “The Expert Educator – A Reference Manual of Teaching Strategies for Quality Education”. Three Blue Herons Pub.

Djuknic, G.m.; Richton, R. E. (2001), “Geolocation and assisted GPS”, Computer, 2001, Vol.34(3), pp.123-125

Flanagan, D. (2006), “JavaScript: The Definitive Guide, 5th Edition”, O’Reilly

93

Group 3, d. 06-06-2013 PPGIS for oil emergency response 3. Semester project, AAU

Fowler, M.; Highsmith, J. (2001), ”The Agile Manifesto”, Software development – The lifecycle starts here.

Freeman, A. (2011), “The definitive guide to HTML5”. Apress.

Fu, P.; Sun, J. (2011), “Web GIS: Principles and Applications”.

Fuglsang, M. (2013), “GIS for mobile applications”. AAU, PP-Slides

Graham, B. B. (2004), “Detail process charting: speaking the language of process.”. John Wiley & Sons

Gomez (2011), “What users want from mobile – July 2011”. Research report made for Equation Research and Compuware

Hansen, H. S. and Prosperi, D. (2005), “Citizen participation and internet GIS – some recent advances”, Computers Environment and Urban Systems, Vol. 29, s. 617-627

Jin, E. W. (2008), “Image quality quantification in camera phone applications”, 2008 IEEE International Conference on Acoustics, Speech and Signal Processing, March April 2008, p. 5336-5339

LaMance, J.; DeSalas, J.; Järvinen, J. (2002), “Assisted GPS: A low-infrastructure approach. (Innovation)”, GPS World, March, 2002, Vol. 13(3), p. 46(6)

Lee, K.-J.; Kim, J.-S. (2012), “Data Quality Control: Crowd-Sourcing Geospatial Information”, Presentation held at UN GGIM Hangzhou, 24-26 May 2012

Leifer, I., (2012), “State of the art satellite and airborne marine oil spill remote sensing: Application to the BP Deepwater Horizon oil spill”, Remote Sensing of Environment, Vol. 124 (2012) p. 185 -209

Lindstrøm, H.; Malmsten, M. (2008), “User-centred design and the next generation OPAC – a perfect match? - A case study of the development of the new version of LIBRIS”. The Swedish National Union Catalogue

Mavrody, S. (2012), “Sergey's HTML5 & CSS3 Quick Reference: HTML5, CSS3 and APIs “, 3rd ed.

Miljøministeriet (2012), “Baggrundsnotat: Pilotproject Mobil Digital Forvaltning – Erfaringer, teknik og organisation”

Mitchell, R. K.; Agle, B. R.; Wood, D. J. (1997), “Toward a theory of stakeholder identification and salience: defining the principle of who and what really counts” The Academy of Management Review. Vol 22. p. 853-886

NCA (2013), NCA’s Contingency plan as of 1.6.2013

Norge digitalt (2013), “Årsrapport Norge digitalt 2012”. Vers. 11.03.2012.

OMG (2009) “UML Superstructure Specification Version 2.2”, OMG

94

Group 3, d. 06-06-2013 PPGIS in oil disaster 3. Semester project, AAU

Perschke, S. (2012), “Six free databases for the enterprise”, Network World Vol. 29, Issue 21 p. 28

PricewaterhouseCoopers (2010), “Evaluering av den statlige oljevernaksjonen etter grunnstøtingen av MV Full City 31. juli 2009”, Report to Kystverket

Præstholm, S. (2012), “Planlægning I hånden på borgeren – fra borgermøde til smartphones og apps?”, Perspektiv nr. 21, 2012

Ramsey P. (2006), “The state of open source GIS”, Refraction Research Inc

Rosso, A.; Bartley, J.; Menon, S. (2012), “Developing with ArcGIS Online”. Paper presented at the ESRI Developer Summit, March 26.-29, 2012, Palm Springs, California

Sarvas, R. (2005), ”User-Centric Metadata for Mobile Photos”, In Proceedings of the Pervasive Image Capture and Sharing: New Social Practices and Implications for Technology Workshop (PICS 2005) at UbiComp 2005 in Tokyo, Japan

Stallman, Richard. (2010), “Free as in freedom (2.0) – and the Free Software Revolution”, Published by the Free Software Foundation, p. 121-122

Steiniger, S.; Hunter, A. J. S. (2013), “The 2012 free and open source GIS software map – A guide to facilitate research, development, and adoption”, Computers, Environment and Urban Systems, Vol. 39 (2013), p. 136-150

UNGGIM (2012), “Future trends in geospatial information management: the five to ten year vision - Draft for consideration by the UN-GGIM Committee of Experts, July 2012”, Background document for the second session United Nations Initiative on Global Geospatial Information Management. New York, 13 – 15 August 2012, 38 pp.

Wang, F.; Ren, X. (2009), “Empirical Evaluation for Finger Input Properties In Multi-touch Interaction” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. Vol. 1, p. 1063-1072

WebMapSolutions (2013), ”Disconnected Mobile ArcGIS Online Editing for Disaster Management Damage Assessment”, Newsletter, April 2013

Verup, K.; Slotta, S.; Klingsheim, J. M.; Yang, W. (2012), “PPGIS – borgerinddragelse ved olieforurening”, 2. semester’s project report, Aalborg University

Zandbergen, P. A.; Barbeau, S. J. (2011), “Positional Accuracy of Assisted GPS Data from High-Sensitivity GPS-enabled Mobile Phones”, Journal of Navigation, 2011, Vol. 64(3), p. 381-399

Webpages: blog.davebouwman.com, (d. 06-06-2013), “Leaflet: Lean, Mean JavaSript Maps” URL: http://blog.davebouwman.com/2011/08/04/leaflet-lean-mean-javascript-maps/

95

Group 3, d. 06-06-2013 PPGIS for oil emergency response 3. Semester project, AAU

commons.wikimedia.org, (d. 03-05-2013), “WGS 84 reference frame” URL: http://commons.wikimedia.org/wiki/File:WGS_84_reference_frame.png

dev.w3.org, (d. 15-04-2013), “Web Storage” URL: http://dev.w3.org/html5/webstorage/

dev.w3.org, (d. 23-04-2013), “HTML5 Web Messaging” URL: http://dev.w3.org/html5/postmsg/

news.netcraft.com, (d. 25-05-2013), “May 2013 Web Server Survey” URL: http://news.netcraft.com/archives/2013/04/19/may-2013-web-server-survey.html

npdwms.npd.no, (d. 17-04-2013), “Welcome to the NPD OGC server” URL: http://npdwms.npd.no/

osgeo-org.1560.x6.nabble.com, (d. 03-05-2013), “Apache and IIS websites” URL: http://osgeo-org.1560.x6.nabble.com/Apache-and-IIS-websites-td5010360.html

resources.arcgis.com, 2013, (d. 21-05-2013), “About geographic data formats” URL: http://resources.arcgis.com/en/help/main/10.1/index.html#//018m00000002000000

resources.arcgis.com, 2013, (d. 22-05-2013), “Supported formats with the Data Interoperability extension” URL: http://resources.arcgis.com/en/help/main/10.1/index.html#/Supported_formats_with_the_Data_Interoperability_extension/004m0000002m000000/

resources.arcgis.com, 2013, (d. 23-05-2013), “ArcGIS.com Service Architecture” URL: http://resources.arcgis.com/en/communities/enterprise-gis/01n20000002m000000.htm

smartphones.findthebest.com, (d. 03-05-2013), “Compare smartphones” URL: http://smartphones.findthebest.com/

techland.time.com, (d. 03-05-2013), “Who’s Winning, iOS or Android? All the Numbers, All in One Place” URL: http://techland.time.com/2013/04/16/ios-vs-android/

tomcat.apache.org, (d. 03-05-2013), “Apache Tomcat” URL: http://tomcat.apache.org/

try.jquery.com, (d. 29-04-2013), “What is jQuery” URL: http://try.jquery.com/levels/1/sections/2

w3cubes.com, (d. 29-04-2013), “Anatomy of a HTML5 mobile application” URL: http://w3cubes.com/blog/2011/10/26/anatomy-of-a-html5-mobile-application/

webhelp.esri.com, (d. 25-05-2013), “Components of ArcGIS Server system” URL: http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#components_of_server.htm

workshops.opengeo.org, (d. 20-05-2013), “Introducing GeoServer” URL: http://workshops.opengeo.org/suiteintro/geoserver/introduction.html

www.agilemodeling.com, (d. 05-04-2013), “Agile Modeling (AM) Home Page - Effective Practices for Modeling and Documentation” URL: www.agilemodeling.com/

96

Group 3, d. 06-06-2013 PPGIS in oil disaster 3. Semester project, AAU

www.binvisions.com, (d. 30-04-2013), “Percentage of websites using HTML5” URL: http://www.binvisions.com/articles/how-many-percentage-web-sites-using-html5/

www.breathingtech.com (d. 06.04.2013), “User stories versus use cases” URL: http://breathingtech.com/2010/user-stories-versus-use-cases/

www.capaxglobal.com (d. 29-04-2013), “Mobile consulting” URL: https://www.capaxglobal.com/solutions/mobile-consulting/

www.diffen.com, (d. 10-04-2013), “A-GPS vs GPS” URL: http://www.diffen.com/difference/A-GPS_vs_GPS

www.digital-photo-secrets.com, (d. 09-04-2013), ”Which quality setting should I use?” URL: http://www.digital-photo-secrets.com/tip/300/which-quality-setting-should-i-use/

www.easybasicphotography.com, (d. 09-04-2013),”Digital Camera Image Sensors and Sensor Size” URL: http://www.easybasicphotography.com/digital-camera-sensors.html

www.easyphp.com, (d. 03-05-2013), “Develop and host” URL: http://www.easyphp.com

www.edepot.com, (d. 03-05-2013), “Iphone, Ipad and Ipod Touch secrets” URL: http://www.edepot.com/iphone.html#iPhone_A-GPS

www.epa.ie, (d. 06-04-2013), “The Environmental Protection Agency (EPA) Ireland’s Smartphone solution for public reporting of environmental pollution” URL: http://www.epa.ie/whatwedo/enforce/report/

www.esri.com, (d. 07-04-2013), “Social Media Maps a Volcano's Aftermath” URL: http://www.esri.com/esri-news/arcnews/spring13articles/social-media-maps-a-volcanos-aftermath

www.esri.com, (d. 07-05-2013), “ArcGIS for desktop” URL: http://www.esri.com/software/arcgis/arcgis-for-desktop/features

www.esri.com, (d. 08-05-2013), “Multiuser Geodatabase” URL: http://www.esri.com/software/arcgis/geodatabase/multi-user-geodatabase

www.esri.com, (28-05-2013), “Simplifying Situational Awareness” URL: http://www.esri.com/news/arcuser/1010/pelicanrescue.html www.esri.com, (d. 01-06-2013), “Open Source Technology and ESRI” URL: http://www.esri.com/news/arcnews/spring11articles/open-source-technology-and-esri.html

www.esri.com, (d. 04-06-2013), “ArcGIS Online Will Change How You Think about Mapping and GIS” URL:http://www.esri.com/news/releases/12-2qtr/arcgis-online-will-change-how-you-think-about-mapping-and-gis.html

www.gatherspace.com, (d. 03-04-2013), “Use Case Examples -- 13 killer tips to create effective use cases “ URL: http://www.gatherspace.com/static/use_case_example.html

www.geoserver.org, (d. 02-05-2013), “Commercial Support” URL: http://www.geoserver.org/display/GEOS/Commercial+Support

97

Group 3, d. 06-06-2013 PPGIS for oil emergency response 3. Semester project, AAU

www.geoserver.org, (d. 03-05-2013), “GeoServer Features” URL: http://www.geoserver.org/display/GEOS/Features

www.geospatialworld.net, (d. 07-04-2013), “Disaster response: User generated data to the rescue” URL: http://www.geospatialworld.net/Paper/Technology/ArticleView.aspx?aid=25327

www.gisdevelopment.net, (d. 20-05-2013), “Applicability of Internet GIS Application in Tourism Industry” URL: http://www.gisdevelopment.net/application/miscellaneous/mi08_193pf.htm

www.govtec.com, (d. 07-04-2013), “Government Technology – GIS-Assisted Disaster Relief in 2013 and beyond” URL: http://www.govtech.com/GIS-Assisted-Disaster-Relief-in-2013-and-Beyond.html

www.gsdidocs.org, (d. 26-05-2013), “The SDI Cookbook, chapter 6 - Geospatial Data Access and Delivery: Open access to data” URL: http://www.gsdidocs.org/GSDIWiki/index.php/Chapter_6

www.ibm.com, (d. 03-05-2013), “Coordinate conversions made easy” URL: http://www.ibm.com/developerworks/java/library/j-coordconvert/

www.icenium.com, (d. 04-05-2013), “What is a Hybrid Mobile App?” URL: http://www.icenium.com/blog/icenium-team-blog/2012/06/14/what-is-a-hybrid-mobile-app-

www.iso.org, (d. 31-05-2013), “ISO/TC211 Geographic information/Geomatics” URL: http://www.iso.org/iso/iso_technical_committee?commid=54904

www.javascripter.net (d. 29-04-2013), “Browsers supporting JavaScript” URL: http://www.javascripter.net/faq/browsers.htm

www.kystverket.no, (d. 23-12-2012), ”Kystinfo er Kystverkets kartløsning på internett” URL: http://www.kystverket.no/Maritime-tjenester/Meldings--og-informasjonstjenester/Kystinfo/

www.leafletjs.com, (d. 20-05-2013), “An Open-Source JavaScript Library for Mobile-Friendly Interactive Maps” URL: http://leafletjs.com/examples/mobile.html

www.looksoftware.com, (d. 23-04-2013), “Web Apps vs. Hybrid Apps vs. Native Apps Part 1“ URL: http://www.looksoftware.com/blog/nick/articletype/articleview/articleid/88/web-apps-vs-hybrid-apps-vs-native-apps-part-1.aspx#.UYSbvxKJVHU

www.miljokommune.no, (d. 03-05-2013), ”Kart og databaser” URL: http://www.miljokommune.no/Kart-og-databaser/

www.mysql.com, (d. 29-04-2013),”Mysql editions” URL: http://www.mysql.com/products/

www.nationalgeographic.com, (d. 07-04-2013), “Digital Disaster Response to Typhoon Pablo” URL: http://newswatch.nationalgeographic.com/2012/12/19/digital-disaster-response/

www.opengeospatial.org, (d. 29-04-2013), “OGC standards” URL: http://www.opengeospatial.org/standards/is

98

Group 3, d. 06-06-2013 PPGIS in oil disaster 3. Semester project, AAU

www.opensource.org, (d. 01-06-2013), “The Open Source Definition” URL: www.opensource.org/osd-annotated

www.openstreetmap.org, (d. 04-06-2013), “Open Street map accessibility” URL: http://wiki.openstreetmap.org/wiki/Software/Mobile

www.oslo.kommune.no, (d. 07-04-2013), “Meld fra om feil og mangler i Oslo” URL: http://www.bymiljoetaten.oslo.kommune.no/meldingstjeneste/

www.osgeo.org, (d. 02-05-2013), “The open source geofoundation” URL: http://www.osgeo.org

http://www.osgeo.1560.x6.nabble.com/,“The open source geofoundation” URL: http://www.osgeo.1560.x6.nabble.com/

www.rideau-info.com, (d. 09-04-2013), ”Geotagging Digital Photos” URL: http://www.rideau-info.com/photos/geotag.html

www.safe.com, (d. 03-05-2013), “About the FME Spatial Data Transformation Platform” URL: http://www.safe.com/fme/fme-technology/

www.stsite.com, (d. 09-04-2013), ”Still Photography Camera Guide” URL: http://stsite.com/camera/cam01.php

www.telenor.dk, (d. 03-05-2013), ”Telenors dækningskort” URL: http://www.telenor.dk/privat/kundeservice/kundeservice/mobil/daekning/

www.uml-diagrams.org, (d. 28-04-2013), ”UML 2.5 diagrams overview” URL: http://www.uml-diagrams.org/uml-25-diagrams.html

www.vordweb.co.uk, (d. 29-04-2013), ”Advantages of CSS” URL: http://www.vordweb.co.uk/css/advantages-of-css.htm

www.w3.org, (d. 30-05-2013), ”Offline Web Application” URL: http://www.w3.org/TR/offline-webapps/

www.w3.org, (d. 26-05-2013), “HTML & CSS” URL: http://www.w3.org/standards/webdesign/htmlcss

www.wampserver.com, (d. 03-05-2013), “Start with WAMPServer” URL: http://www.wampserver.com

www.youtube.com, (d. 03-05-2013), “Oil spill situation in the Mexico Gulf 14th May 2010” URL: http://www.youtube.com/watch?v=JfOinnQeHIY www.1stwebdesigner.com, (d. 02-05-2013), “How to Build a Website:” URL: http://www.1stwebdesigner.com/resource/build-a-website/

xampp.en.softonic.com, (d. 03-05-2013), “Upload your work locally with superb tool” URL: http://xampp.en.softonic.com/

99

Group 3, d. 06-06-2013 PPGIS for oil emergency response 3. Semester project, AAU

Personal communication: Berger, Silje (pers. comm.), From conversations with Silje Berger under the work with the specification of the new system “Map based emergency response solution”. Berger works at NCA’s preparedness Centre.

Kjeldsen, Bent Gaardsvig (pers. comm.), From conversation with Bent Gaardsvig Kjeldsen under a meeting between him and our project group 01-02-2013.

Oksnes, Rune (pers. comm.), From conversations with Rune Oksnes under the implementation of the NCA's Open Source-based SDI. Oksnes working in the IT section of the NCA.

100

Group 3, d. 06-06-2013 PPGIS in oil disaster 3. Semester project, AAU

11 Appendices

Appendix 1 - Interviews with two citizens

Appendix 2 - NCA Procedures on Information

Appendix 3 - The seven Use Cases

Appendix 4 - An UML class diagram giving a detailed data structure model based on the seven Use Cases.

Appendix 5 - Comparison of the Web Map servers Geoserver and ArcGIS Server

Appendix 6 - CSS3 Reference

Appendix 7 - Flow model visualizing ESRI standard App’s full capabilities (whole model) and the used part of it (within the red boundary) when the Use Case 1’ prototype is used on ESRI’s standard App for Smartphone’s (iOS)

101

Kim Verup, John Morten Klingsheim, Simen Slotta, Weixiao Yang

MTM – Master of Technology Management with specialization in Geoinformatics and Geoinformation management

3. semester, 2012

Aalborg Universitet