Bachelor Thesis - Flood Simulation BrowserBachelor Thesis - Flood Simulation Browser F.S.B. more...

Bachelor Thesis - Flood Simulation Browser

July 12, 2012

Supervisor: Student:Robert Belleman - U.v.A Richard Torenvliet

stdnmr: [email protected] [email protected]

Bachelor Thesis - Flood Simulation Browser F.S.B.Contents

1 Introduction 3

I Discovering the subject 4

2 Flood Simulation System 4

3 Flood Simulation App 5

3.1 Platform considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Phonegap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2 Overview frameworks . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 App Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

II Implementation Details 14

4 Server API 14

5 Sencha Touch 2 14

5.1 Stores and Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Layouts and xtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.5 Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.6 Chart Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Scalability 22

6.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1

Bachelor Thesis - Flood Simulation Browser F.S.B.

7 Deployment 26

7.1 Get the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8 Does Sencha Touch suffice 27

9 Conclusion 28

10 Discussion 28

A Area API 33

B LSM 36

C drfsm 39

2


Abstract

In this thesis we discuss the design and implementation of a cross platform ap-plication, designed specifically for tablets, that assists the UrbanFlood project inmaking simulated flood more accessible for viewing simulations. This applicationfor viewing simulated floods was already available on a multi-touch table, which isnot easily transportable. To reach to goal of mobility, and to reach a larger audience,it is desirable to have a more portable instrument. As tablets have the same interac-tion features as the multi-touch table, they are the ultimate tool to achieve this goal.Sencha Touch 2 was found to be the best option at first to build a cross-platform ap-plication, but a more in-depth study showed that it could not fully live up to theexpectations. A second objective of the present study is to test how many clientscan be handled by the back end server at ones. Tests show that the response timegoes up considerably with the number of users, which shows that there are alsoserver side problems to be solved before widely applying the developed software.

1 Introduction

UrbanFlood is a European project that aims to create an early warning system in Euro-pean cities [17]. In the today’s changing climate, more and more cities have to deal withfloods more often. An article of [24]. A lot of research went in the possible solutionsfor specific problems. Due to extreme rainfall, rising water or long lasting drought, theinstruments that protect the civilians of a certain area are negatively influenced. Theproject involves setting up a system that can make estimates on how a levee would be-have in the near future. Vigilance against weak spots in the levee is needed 24/7. To dothis they placed sensors in the levee that can be monitored remotely via internet. Butthis not the only concern. They also developed a system that can create flood simula-tions of a certain area. This is used for testing dikes in a possible scenario but also foreducative proposes. This subject is discussed in the present document.

This thesis concerns the Flood Simulation Browser. The concept of this browser is toillustrate/visualize a flood in a particular area. With this technology people can see theflow that the water will take. When a dike breaks it is important to know where the wa-ter will flow. Information about which locations in the area will be under water first canresult in a successful evacuation plan. This system already exists on a multi-touch ta-ble [10]. The touch table is used in workshops for an interactive way of informing aboutthe risk of floods. The disadvantage of the multi touch table is that it is only accessiblein certain occasions. If the system were to be more accessible it makes it more likelythat someone with right authority can take better decisions about placing/reinforcinga levee or creating evacuation plans. Moreover, if this system is more accessible, civil-ians of a certain area that is threatened by water, have the ability to gain knowledge ofwhere the water will go first. They then are able to take the the right crucial decisions,based on this knowledge in the hour of need. To solve the problem of accessibility asolution has to be found.

Tablets are devices that support the same multi-touch gestures and are more accessiblethan the multi-touch table. That’s why the aim of this thesis will be an implemen-tation of the Flood Simulation Browser on such a device. In particular iPad [7] andAndroid [2] tablets. Users can take use of this application in an intuitive way, to get

3


more intelligence about the complex situation at hand. They have the ability to choosefrom several simulations that were already made for a specific area and also new sim-ulations. In order to reach more accessibility, a deployment for both iPad and Androidis preferred. The search for such a solution is second part of this thesis.

A third objective of this study is testing the scalability of the server. By testing howmuch requests the server can handle at once it helps the urban flood project to estimatehow many users can use the application simultaneously. The original multi touch ap-plication on the multi touch table was only one client for the server. It’s important toknow that an early warning system stays online under the heavy load of a multitude ofclients.

This thesis covers the design choices that where made in order to reach those goal. Thefirst step is to get an idea of the existing simulation system this application will makeuse of This includes a description of where this application is situated in the UrbanFlood Project as a whole. The study also includes an examination of the capabilitiesof the different devices available, as well as a requirement analysis specifically for thisapplication. The resulting app will extend the simulation with a use-ability and aboveall mobility factor. Of course, performance is one of the main issues here.

This concludes the following research questions.

• Is it possible to implement the Flood Simulation Browser on tablet in a useful andintuitive way?

• Can this be done crossplatform?

• Is the current server of the API adequate to serve a large number of clients

The first part of this document will describe the global information needed to answerthe research questions. The second part describes the implementation, considering thefindings of the first part.

Part I

Discovering the subject

2 Flood Simulation System

Two systems are involved in creating the backbone and resource for the Flood Simula-tion Browser(F.S.B). One part is the system where the client application directly com-municates to and where the API is stalled, specifically at sangkil.science.uva.nl.The API is used by the client applications to get the appropriate data. The other is usedby API to create new simulations when a request at client side is made. The systemat sangkil makes use of the "Common Information Space"(CIS) [21]. This communi-cation system is never used directly by the end user. New simulations are started via

4

sangkil.science.uva.nl


this communcation system, which is also more widely used in the Early Warning Sys-tem to share information between different systems, e.g. monitoring data of the dikesand the alarm(Attention Level Manager). The systems are needed for retrieving dataabout a simulation and ultimately to display the simulations. The F.S.B. is a GUI thatcan display the simulations on a map. The simulations itself were made by the HRWallingford’s [6] simulation software and generated in the cloud [26]. The simulationscan then be retrieved from sangkil.science.uva.nl.

The simulation programs of HR Wallingsford runs in the cloud. The cloud services arerunning on virtual Windows machines that can start the simulation if the right param-eters are provided. For instance, the location and how much water the user wants togenerate. The flood simulation system performs a complex simulation. In the Nether-lands the AHN(Actueel Hoogtebestand Nederland) [1] data is used to do such a sim-ulation. The AHN is a height map that holds detailed information about the height ofan area. With this data the flow of the water can be calculated and turned in to im-ages. These images are used by the client’s application, this an important part the F.S.B.With calls(GET or POST) to the API at sangkil, it returns a set of simulations that arepresent on the machine. The important thing to note is that the final simulations areimages. These images are ready to be displayed on a map, e.g. Google Maps. Not onlydoes the system have the capability to calculate the flow of water, but it can also calcu-late the estimated route that people take when a flooding takes place. It can calculatehow much people would survive a simulated flood, keeping in mind that this projectis all about saving people, this is interesting information.

3 Flood Simulation App

3.1 Platform considerations

3.1.1 Phonegap

As stated in the introduction the application is meant for tablets, but not specificallyfor iOS or Android. Which means cross-platform. How to maintain the cross-platformdemand on the application is one of the subjects of this project. This means that theapplication is not a native implementation and consists of one code-base and runs onmore devices. There is a tool called PhoneGap [12] that uses HTML5 [27], CSS3 [20]and Javascript to build the app. In essence the developer builds a mobile website andPhoneGap can wrap this in an application. The native web-engine is used to renderthe mobile website. PhoneGap can result in a huge speed-up in development time,which is a huge advantage. The speed up can be obtained by the fact that previouslygained skills of webdevelopment can be re-used. Therefore there is no need to learna new programming language or sdk [15] for native apps. For example Objective Cfor iOS and Java for Android. The disadvantage can be that the application feels morelike a mobile website than a real app. In addition, the end product depends on thesupport of today’s web-standards. Not all browsers have full support for HTML5 andCSS3, which forms the bases of a successful implementation of the application. Fora list of supported elements, websites like caniuse.com [4] can be used to determine

5


sangkil


the percentage of support for a certain element/feature. But that does not really help.Nevertheless, the lack of the native feel oan application can be remedied. For example,frameworks where native-like elements are created for you while coding in a program-ming language already known by a webdeveloper also exist.

Titanium

This solution is Titanium Mobile, the Appcelerator [3]. Titanium Mobile can build mo-bile applications that are in fact native applications. By programming in Javascript andcall functions to create native elements the application can be created. The frameworkbuilds semi-native code, unlike the previously discussed PhoneGap. The developmentfor this platform is fast and an application for both iOS and Android are quickly offthe ground. But there is also a disadvantage to using Titanium. The applications arebig, around 11MB no matter what. Because of the fact that the logic will still be injavascript(compiled), Titanium has to ship their javascript engine to the device. But notonly do Titanium generated apps take a lot of space, it also has trouble with memory.This is partly from own experience. The application is sometimes killed for no apparentreason. With a little research on the web, I found that I was not the only one facing thisproblem, see this blog-post [22]. The blog-post discusses this issue, both developersand users discuss this issue in the reactions. Although this blog post refers to version1.6 and 2.0 is already out, we consider the uncertainty about this behaviour of Titaniumtoo great of a risk for the present project.

Developing and testing on iOS provides expected behaviour and a large part of nativeelements are supported. But for Android the native elements are mostly not the ele-ments you thought they would look like. To reach cross-platform apps, the developerneeds to constantly keep track if they’re building an element for iOS or for Android.It might be stated that the functionalities of different platforms are not evenly sup-ported. iOS is by far the most supported platform. This only provides an advantageif the project only meant to run on iOS. The idea of Titanium Mobile is great, it worksfine but will delay developing time when you truly want to reach crossplatform. Alsothe fact that this application needs a map that supports overlays for the simulation im-ages is a big disadvantage. By searching trough the documentation 1, the only thing itsupports is adding an annotation. An annotation is just a marker placed on the mapwith the ability to get de latitude and longitude of the marker. To sum up, Titaniumlacks support for both platform and map object, at the same time it can surprise thedeveloper in an unpleasant way by taking a lot storage and a buggy garbage collection.

Building crossplatform and creating native elements could mean a risk for completingthe application. A browser is the only thing that has the most equality on both devices,i.e. both Android’s and iOS’s native browsers are based on the webkit engine [18].Webkit is an open source web engine that is used by both Safari and Chrome.

1http://docs.appcelerator.com/titanium/2.1/index.html#!/api/Titanium.Map

6

http://docs.appcelerator.com/titanium/2.1/index.html#!/api/Titanium.Map


Javascipt frameworks

As already explained, PhoneGap creates an app out of a website. This website can bebuilt in any way the developer likes, using web technologies supported on the nativedevice. There are frameworks that can speed up the development to make an intuitiveapplication. Two frameworks that are considered are: jQuery Mobile [8] and SenchaTouch 2 [16].

jQuery Mobile This Javascript framework is build out of one Javascript file and oneCSS file that the developer includes. By giving certain HTML elements a dataattribute, which is a HTML5 element, the framework uses this to create views. Apage is made by declaring a div adding data-role="page". Such a page can begiven a footer like div data-role="footer". Switching frame one page to theother can be as simple as giving a html anchor’s href to an id of another page.Listing ?? provides an example that will result in two pages, this is to illustratethe easy use of this frame work. Both pages have a button. Both buttons link tothe other page (foo, bar), so tapping on one button will change the page to theother page. jQuery Mobile catches the requests that is made when a user taps ona button. It then uses Ajax to handle the request and push the new page in theview.

Listing 1: jQuery Mobile, pages example

<div data−r o l e =" page " id = ’ bar ’ ><a # hre f = ’ foo ’ data−r o l e =" button "> switch to foo </a>

</div ><div data−r o l e = ’page ’ id = ’ foo ’ >

<a # hre f = ’ bar ’ data−r o l e =" button "> switch to bar </a></div >

Creating two pages is quickly done, the downside of jQuery mobile is that in or-der to create an application where views look alike, you have to repeat yourself.You have to create pages with other id’s and with the same look/elements butwith different information. The conclusion for jQuery mobile is that it is easyand the developer does indeed use HTML5, CSS3 to create views. But it is noteasy to built a modular application. It is always possible to create such a modularapplication yourself, but when creating an application which is not such a frame-work the developer will run in to creating a framework in stead of the intendedapplication.

Sencha Touch 2 Sencha touch 2 is a framework that is based on the Model View Con-troller design pattern [25]. It encourages the developer to use this pattern. Theway of developing really differs from jQuery mobile. Where jQuery mobile setsyou free to do whatever you like, Sencha Touch constraints the developer usingcomponents that are available in Sencha Touch. The difference can be easily ex-plained with an example.

In the items array, see Listing 2, the items in that array can be anything supportedby Sencha Touch like lists, a tabview, a map, etcetera. The difference betweenjQuery and Sencha Touch is clearly noticable in the listings 1 and 2.

7


A real convenience of the Sencha Touch 2 framework, provides a command-linetool to build a starting environment. It creates files where the developer can startfrom. It is recommended to use this as a starting point. The advantage is anapplication that is structured out of the box with a design pattern that is a wellknown standard for these kind of applications(MVC).

Also, with Sencha Touch 2 there is no need for PhoneGap. Sencha Touch 2 pro-vides the functionality to run the code on your simulator or native device withthe command line tool of sencha. Testing for Android and iOS became muchmore simple, resulting in less developing time. Running PhoneGap for Android,needs Eclipse [5] to build, for iOS the developer needs to build in Xcode [19].When testing on both devices the developer needs to be able to test in both en-vironments, and testing from the command-line is a lot easier than running bothenvironments.

A disadvantage of Sencha Touch could be, as seen in listing 2, the syntax of SenchaTouch is not so easy at first. So the learning curve could be very steep. The lastargument that has a great influence on deciding which framework to use, couldbe that Sencha Touch provides an add-on that has the capability to create multi-touch charts. The original implementation of the urban flood browser on themulti-touch table has this feature. It would be a great extension of the project ifthis was possible. So with an eye on the future it could save a lot trouble, and itcould add up to a more intuitive design.

Listing 2: Sencha Touch application example. This example creates an application with the name ’foo’.The html can be placed inside the items array

Ext . a p p l i c a t i o n ( {name : ’ foo ’ ,launch : funct ion ( ) {

Ext . c r e a t e ( " Ext . tab . Panel " , {f u l l s c r e e n : true ,i tems : [

{t i t l e : ’ bar ’ ,i conCls : ’ bar ’ ,html : ’ bar ’

}]

} ) ;}

} ) ;

8


3.1.2 Overview frameworks

The following table is an overview of the previously discussed properties of tools; Tita-nium, jQuery Mobile in combination with Phonegap and Sencha Touch.

+ is positive, - is negative, – strong negative, ++ strongly positivecross learn. curve modular docs supported comp. perform. dev time

Titanium - - - - – - +jQuery Mobile + – – + - - ++Sencha Touch 2 + - + + + - +

Sencha Touch 2 has the most positive signs based on the previous sections. Thereforethe platform Sencha Touch is selected as the tool to implement the F.S.B.

3.2 Requirements Analysis

Requirement analysis for this project exists out of an inventory of tasks that the applica-tion has to be able to perform. For example, displaying a list or controls or a graph. Theapplication needs components for interaction and displaying of data. The componentsare described in the following.

List First, the users need to be able to see different simulations and be able to distin-guish where certain simulations are located. The locations are mostly named bycities. The corresponding simulations have to be retrieved from the server anddisplayed in a list. Those list-items are the individual simulations, so it makessense that when tapping on a list item, the simulation of the related item is goingto be displayed.

Map The form of these simulations are important. The simulations are in the form ofimages. These images are images from above and can be placed on the map. Inorder to display these images, there has to be a map available. This is the mostimportant object of the application and has to be prominent place in the view.

Controls As stated before, the flood simulations are in the form of multiple imagesthat are placed on the map. A requirement for these simulation images is that theuser can control which image it wants to see in a chronological way, To do this,the user would need controls. These controls need to be appear in the viewportwhen the user has tapped on a list item of a simulation.

Chart The flood simulations contain information about how much water is present ina certain timestep in a specific location. This information needs to be displayedin such a way that it can be interpreted by the user. This requires a chart with thetimesteps on the x-axis and another value like volume on the y-axis. To determinethe zone which contains the information, latitude and longitude information isneeded again.

Simulation’s Switcher Next to flood simulation, also population dynamics simula-tions are available. Therefore controls are needed to change the simulation type.

9


These simulations also have a location and time steps, so the same map can beused to display these simulations.

These requirements are taken in to account in the applications design. The next sectionwill cover design choices in the App’s design.

3.3 App Design

The application will be used on tablets so that a lot of space can be used. On tabletsthe screen is larger than on mobile phones. Which can result in a bigger travel distanceof the user’s hands. The GUI design has to be built with the considerations of theinteraction capability of the users. For instance, unlike with mobile phones, accordingto Clark(2012) a leading designer in creating multi-touch applications, people tend tohold a tablet on the top halve of the tablet when holding with both hands, Figure 1.The focus of the user is going from top to bottom. The top elements of the applicationwill draw the first attention of the user. That’s why Clark(2012) advises to place theimportant controls on the top half of the view. The components that are important haveto be placed in the left or right top, concerning the perimeter of the thumbs, Figure 1.The F.S.B.’s design heeds Clark’s advice.

Figure 1: Portrait touch perimeter(Clark, 2012)

First of all the flood simulations are done within different cities. This can typically be alist of cities. The list is scrollable and can be seen as an "infinite" array of cities aroundthe world. Every city has its own array of simulations to show. It therefore makes senseto also show these in a list. When a city is selected, the user has no use of the capability

10


to select other cities and its simulations. That’s why the list of cities are pushed out ofthe viewport and the list of simulations is pushed in. It also makes sense to have oneMap object in the view, where one city (latitude, longitude) can be shown at a time. Themap object is the most important component of the F.S.B. and therefore takes the biggestspace. It also makes it easier to pan and zoom the map. The list component where citiesand simulations are placed is at the left side of the view. It could also be the right sidebut it would not matter. Since two hands are more or less symmetrical, so placing thelist object left or right would not be a problem. It does matter concerning controls.Controls to change the timestep of a simulation are definitely needed. A simulationconsists of multiple images on different time steps. By giving the user control of whichimage is seen at which time step is a crucial feature in the browser. Since the list isplaced in on the left side of the screen, the controls appear in the right top part of thescreen. That way the perimeter of the movement of the thumbs are taken in to account.

Figure 2: Cities list out of final application

The F.S.B. that is already built for the multi-touch table has the ability to submit newsimulations to be simulated in the cloud. The spot of the simulation can be arbitraryon the map, by simply touching a place on the map and alter some parameters, thecloud service calculates a new simulation. Although this feature can be an seen as anextension of my project, with time left this feature can be build in. That’s why it can bediscussed in the App’s design. The controls of these parameters need to be somewherein view, by placing this in the neighbourhood where the user touches the map could beintuitive. However, this should never happen when the user is just navigating over themap, the user has to know that if he or she is the mode of with picking a place whereto create a new simulation.

Furthermore, it’s an important feature to display data of a simulation in certain area.The API provides this data. It holds information about how much water flows in thatarea over time. This data is the volume of water per time step. The API requests lat-itude, longitude values, it then returns data of a location that is closest to this point.When a user taps on the map a marker is put down to annotate the just selected area,next the chart appears with the just selected data. Charts are great way to display this

11


Figure 3: When Amsterdam is selected, the map moves the center of the map to Amsterdam. In thisscreenshot, a simulation is also selected

data. See Figure for the final implementation.

Figure 4: Chart functionality in final application

3.4 Scalability

The second assignment of this thesis is to test the scalability of the server. The serveraddress is sangkil.science.uva.nl. To test this server it is required to excludeany other parameter of the client. That way, the maximum values of the server aretested and not the limitations of the client. To get these values, the server mangkus.science.uva.nl, that is located in the same network as sangkil.science.uva.nl, is used for testing. The servers have the exact same specifications, so this is ideal fortesting the maximum values of sangkil.science.uva.nl. Again, this is not a realistic test

12


mangkus.science.uva.nl





but it is meant to find the maximum values. For stress testing the server a tool calledsiege [23] is used. With this tool it is possible to launch requests to a url with n-nodesand k-connections executed per second. Siege registers the following data:

• Transactions - total hits

• Availability - percentage of total succeeded hits

• Elapsed Time - seconds

• Data Transferred - MB

• Response Time - seconds

• Transaction Rate - TransactionsElapsedT ime

• Throughput - MB/s

• Concurrency - rate of concurrency

• Succesful transaction - number of succeeded hits

• Failed transactions - number of failed hits

• Longest transaction - seconds

• Shortest transaction - seconds

With this data new insight can be provided. By increasing the number of simultaneousconnections, values could start to change. To really give the server a stress test, it ispossible to provide a list of urls which can randomly be picked and executed. Thissimulates a more likely scenario and provides more insight on how the server wouldbehave in a real situation. The expectation is that the response time might grow as thenumber of clients starts to grow. With more clients to serve, it could take longer if thereare more clients active. If processor power is limited, maximum available memory isreached or even the implementation of the server for handling requests could all havean effect in the response time, or any other variable. The research for which variableschanges, together with the cause and the solution is a part of this project and will bedocumented in the end report.

End of Part one

Part I describes the questions and some answers on what the approach of tackling thisproblem is going to be. For an understanding of what global problems are faced in thisproject, it will be sufficient to have read part one. Part II holds information about howthe implementation is made, the problems that where discovered in process, resultsare displayed and discussed and ultimately ending with the conclusion of this project.Note that filenames are addressed in this part. The code can be found on github, [email protected]:icyrizard/FloodSimulation-Browser.git

13

[email protected]:icyrizard/FloodSimulation-Browser.git

[email protected]:icyrizard/FloodSimulation-Browser.git


Part II

Implementation Details

4 Server API

A clear understanding of which requests have to be done in order to gain the right infor-mation, is needed before beginning with any implementation. The full api is referencedin the appendix A, B and C. The appendix is referenced and used for explanations inthe following sections.

5 Sencha Touch 2

The final choice for the development of this application was made in favor of SenchaTouch 2. Sencha Touch provides cross-platform capability and is based on web tech-nology. Although Sencha Touch comes with a unique syntax, based on Ext, the content,look and logic is based on web languages. Part I section 3.3 the design of a touch appli-cation is discussed. The application is going to be created with the findings describedin that section.

Sencha Touch is based on MVC with the addition of stores. Stores can hold informationof whatever the application needs, more about this in a moment. The model is usedfor the communication with the database, the controller stands between the model andthe view. The controller can steer between views and handle logic. The application hasno direct need of models, since there is no database that has to be updated. Stores canhandle enough communication between the server and the application.

5.1 Stores and Lists

The stores in this application are used for filling the lists. In particular the cities list ensimulationslist. A list object is defined as follows.

14


s t o r e = Ext . c r e a t e ( ’ Ext . data . Store ’ {f i e l d s : [ ’ name ’ , ’ corners ’ , ’ visbounds ’ , ’ area_id ’ , ’ center ’ , ’ s ize ’ ] ,

proxy : {type : ’ r e s t ’ ,u r l : ’ ht tp :// sangki l . s c i e n c e . uva . nl :8003/ area/ l i s t . json ’ ,reader : {

type : ’ json ’ ,rootProperty : ’ areas ’

} ,}

} ) ;Ext . c r e a t e ( ’ Ext . L i s t ’ , {

t i t l e : ’ l o c a t i o n s ’ ,s t o r e : ’ c i t y s t o r e ’ ,itemTpl : ’ < div >{name}</div > ’ ,

} ) ;

Figure 5: List of cities

The store is automatically updated when the values change on the server. When some-thing changes in the store, the list is also automatically updated. The specified fieldsare available in the list, containing the name of the field between brackets { }, thefield name of record n is placed in list item n. Five stores are present in the application.SimulationStore.js, SimulationDetailStore.js, LsmStore.js, SimulationsSummary.js,ChartStore.js.

• SimulationStore.jsfields: [’name’, ’corners’, ’visbounds’, ’area_id’, ’center’]Is in sync with http://sangkil.science.uva.nl:8003/area/list.jsonon the server. Locally the store is in sync with the view List.js. Basically thisstore returns information of the simulation locations that are available. The mostimportant data are the name, center, visbounds and area_id. With the name fordisplaying in the list-item; the center for changing the map’s center to the loca-tion of the simulation and the visbounds are used for the image overlay. Thevisbounds are used to scale the image on the tiled map, it contains the lat,lnginformation of the south west and north east locations of the square. When theuser taps on a list-item, the data of longitude and latitude information is used tochange the center of the map and push a new list over the current list, since a tapevent on a list-item returns the tapped item and the store used for creating thislist. The second list holds information about which all the simulations available.

• FloodDetailStore.jsFields: [’name’, ’center’, ’corners’, ’size’, ’extents’,’visbounds’, ’vissize’, ’projection’, ’dikes’]Is in sync with multiple urls, http://sangkil.science.uva.nl:8003/area/<area_id>/info.json, where the area is the area that is selected in List.js.This store adds information of dikes. The rest of the data is already present in theSimulationStore.js. The dikes consists of eight values, which are 4 corners with

15

http://sangkil.science.uva.nl:8003/area/list.json

http://sangkil.science.uva.nl:8003/area/<area_id>/info.json

http://sangkil.science.uva.nl:8003/area/<area_id>/info.json


a latitude and longitude value. This means that a polygon can be formed fromthese four locations and displayed on the map.

• LsmDetailStore.jsFields: [’area_id’, ’test_id’, ’submitted’]This store holds information of the population dynamics, meaning how the evac-uation of the individuals will proceed.

• SimulationSummary.jsFields :[’area_id’, ’test_id’, ’submitted’],Syncs with http://sangkil.science.uva.nl:8003/drfsm/list.json?summary. This returns a JSON string that holds a list of all the simulations. Astore can be filtered on a certain value. All the simulations have an area_id spec-ified. The store is filtered on the area_id selected in List.js. Note that filters staypresent, so before doing anything the store has to be cleared of all the filters.

• ChartStore.jsFields: [’time’, ’volume’]This store is used for creating the chart. The chart expects a jsonStore with dataand fields to plot. The data is retrieved from the server at run time of the applica-tion in Api.js and set in the store by the setData function.

Figure 6: A list of cities in the final application

5.2 Layouts and xtype

Layouts in Sencha Touch provide a structure for placing components and are fairly easyto create. A layout keyword is placed in the Container component which functions as acontainer for other components. That way the developer can build a hierarchical view.Child components are placed in the items key array. These can be any component thedeveloper likes. A layout in this application is used once in app/view/main.js.

16

http://sangkil.science.uva.nl:8003/drfsm/list.json?summary

http://sangkil.science.uva.nl:8003/drfsm/list.json?summary

app/view/main.js


Figure 7: layout with hbox

Next to the type layout hbox also vbox exists, which divides the viewport vertically.The xtype keyword tells Sencha Touch which component to place in the container. Flex1 or flex 2 tells the container on which side of the container the components needsto situated. See 8 for how these are used to as a reference. The image of figure 7 isimplemented in figure 8.

Ext . def ine ( " app . view . Main " , {extend : ’ Ext . Container ’ ,conf ig : {

t i t l e : " Simulat ion Browser " ,layout : " hbox " ,f u l l s c r e e n : true ,i tems : [{

xtype : ’ l i s t p a n e l ’ ,f l e x : 1 ,

} ,{

xtype : ’ s imulat ionpanel ’ ,f l e x : 2

} ] ,}

} ) ;

Figure 8: Layout in app/view/Main.js

The xtype keyword matches the keyword out of the component where the xtype isdefined. It serves as shortcut to the full component. Components that are created canget a unique xtype value and be referred to by other components to call functions or fordisplaying of that component, this is widely used throughout the application.

17


5.3 Controllers

Controllers perform the logic in the application. They react on events, fired by the ele-ments in the view. In Sencha Touch the events are configured in the control configura-tion. References to components in the view are created in the ref attribute in the configattribute. A reference may consist of a css selector or an xtype name, or both. Refer-ences are used in the functions below the config field, this.getMap(). Controllersare declared like the following.

Ext . def ine ( ’ app . c o n t r o l l e r . Main ’ , {extend : ’ Ext . app . Contro l ler ’ ,conf ig : {

r e f s : {map : Map

}

c o n t r o l : {# button : {

tap : tappedButton}

}}

tappedButton : funct ion ( ) {t h i s . getMap ( ) . dofunction ( ) ;

}} ) ;

In the application two controllers exists, a app/controller/main.js controller forhandling logic for the general view and simulations. Another controller namedapp/controller/chartController.js is used for dealing with the chart infor-mation. Both make use of loading stores, getting a component to be pushed in to theview when the right event is passed. And when the view needs more data than storescan get, the controllers make use of the app/Api.js.

5.4 Map

The map object in Sencha Touch 2 is created by creating a view and extending Ext.map.Since Sencha Touch 2 became available Google Maps is a build-in type. Because of theway the map is really an instance of the google maps api. I decided to let the Mapview extend that api, and let the controller call those functions just like it would whenit talks to the google maps api. This choice is made not only done for conveniencebut the ability to create multiple controllers to talk to the same map would be a biggeradvantage than placing this in a separate controller. Also by initiating a map that isbased on another tiled map object like open street view that uses the same functionnames. A quick change between different maps could be established.

A map object is declared like the following.

18


Ext . def ine ( ’ app . view . Map’ , {extend : " Ext .Map" ,

id : ’mapa ’ ,xtype : ’ SimulationMap ’ ,

conf ig : {useLoadMask : true ,mapOptions :}

} ,

func : func t ion ( ) {}

} ) ;

In the application the Map object extends and uses the Google API. Overlays are usedfor placing simulations images on the map. When the maprender event is fired, itreturns a reference to the Google API and Ext Map component. The Google MapsAPI specified in the documentation is used for creating overlays and adding markerson a certain Lat, Lng. The most important feature is initializing the first image bycalling createOverlayImage function when a simulation is tapped in the list andcreating overlays for the rest of the timesteps. These images are stepped through in thenextImage and prevImage function. Which are controlled when a button in the controlpanel is tapped.

5.5 Controls

The controls to change the simulation step when a simulation is selected, appears inthe right top of the screen. The component has four controls; forward, backwards, playforward, play backwards. Because off the fact that the controls take space of the map,the background of the controls is transparent for creating the feeling of more space.

Figure 9: Controls

By tapping on the upper button, the next image is placed on the map. The right buttonplays through the simulation automatically. The left and bottom button both do theopposite. Also a pause button stops calling the next or prevImage function out the mapobject. As previously discussed, the controls appear in the right top of the screen. If theuser needs the controls on the bottom part of the screen, the user can also tap and dragthe controls. Because the space of the tablet is limited the user can make the decision of

19


placing the controls somewhere else, note that the controls are constrained to the rightside of the screen. The reason is that the controls are meant to be used by the user’sright hand.

5.6 Chart Display

The chart data is displayed when the user taps on a simulation image on the map. Thegoogle maps API supports the click event, the event has a payload where the latitudeand longitude data can be obtained. A marker is put down at that location and the API(at sangkil) is called to retrieve the izid of the tapped lat,lng. When the izid is known,a second request has to be done to obtain the corresponding .csv file. See listing ?? forthe requests.

Listing 3: requests for flood data

/∗ obta in i z i d ∗/http :// sangki l . s c i e n c e . uva . nl :8003/ area/<area_id >/ i z i d . j son ? l a t l n g =< l a t > ,< lng >/∗ obta in csv f i l e ∗/http :// sangki l . s c i e n c e . uva . nl :8003/ drfsm/< t e s t _ i d >/ r e s u l t s / i z i d /<iz id >. csv

A response looks like the following.

Listing 4: csv response

time , iz id , volume , l e v e l , dischargex , dischargey6 0 0 , 5 0 2 2 , 8 3 8 . 0 8 2 , −4 . 8 4 1 8 9 7 , 0 . 0 , 0 . 0900 ,5022 ,852 .3604 , −4 .835319 ,356 .0 ,0 .001675895. . .

The first value is the time step of the simulation, the third is the volume. The chart willdisplay the volume (in cubic meters) on the y-axis and the time steps on the x-axis. Bysimply splitting on a "," and placing the value at position 0 and position 2 of every lineexcept line 0, in a separate array and feed in to ChartStore.js, as discribed in section5.1, and plot the data.

The plot is made with Sencha Chart. The chart has to be rendered to a certain container.In application this is a Ext.Panel, that supports the showBy() function. Which meansthat the panel with the chart can be placed in the view at a certain position. In the itemsarray, xytpe: ’chart’ is placed, Sencha now knows what kind of component to placeinside the Ext.Panel. The chart itself has a couple of fields that are necessary in order toplot the data. First of all the name of the jsonStore,

Listing 5: Chart component app/view/Chart.js

Ext . def ine ( ’ app . view . Chart ’ , {extend : ’ Ext . Panel ’ ,

id : ’ f lood−chart ’ ,xtype : ’ f loodChart ’ ,

r e q u i r e s : [ ’ Ext . data . Store ’ ] ,conf ig : [ {

20


i tems : [ {xtype : ’ chart ’ ,s t o r e : ’ char tS tore ’ ,axes : [

{type : ’ Numeric ’ ,p o s i t i o n : ’ l e f t ’ ,f i e l d s : [ ’ volume ’ ]

} ,{

type : ’ Category ’ ,p o s i t i o n : ’ bottom ’ ,f i e l d s : [ ’ Time Steps ’ ]

}]s e r i e s : [ {

type : ’ l i n e ’ ,xF ie ld : [ ’ time ’ ] ,yFie ld : [ ’ volume ’ ] ,

} ] ,} ]

} ]} ) :

The series attribute in the Chart configuration means what kind of plots are going todisplayed. So it is possible to create more series and display different types of datain the chart. Also because the chart can be fairly large, this component is also madedraggable for the user to create more space.

Figure 10: The chart in the final application

21


6 Scalability

The server sangkil.science.uva.nl is tested on scalability. The server specifica-tions are two Intel(R) Xeon(R) CPU E5620 @ 2.40GHz processors, with both 4 cores and8 threats and 23GiB of memory. An important part to notice when testing a server ishow well it performs depending on the number of peers it is serving. By looking athow the response time will change if the number of clients increases, can tell how therate of scalability. The number of clients a server can serve simultaneously is of coursethe number 1 issue in scalability. So how do the values change when connections, andtherefore client numbers, start to rise.

To test the server, all bottlenecks at client side have to be brought down to a minimum.mangkus.science.uva.nl is the address of another server with the same specifica-tions. The mangkus server is situated in the same server rack as sangkil, and hasthe exact same specifications. The TCP/IP packages do not have to travel around theworld in order to reach the destination, so the response time when not in a stress testcould be in optimum state.

6.1 Testing

So testing the sangkil server is done from the server mangkus. A tool siege is used fortesting the server, previously discussed in section 3.4 in part one.

$ s i e g e − i −b −f f i l e . t x t −c $1 −r $2− i randomly picking request out of f i l e . t x t−b no delay between the next request a c l i e n t does−c concurrent processes−r number of r e p e t i t i o n s

Testing is done by changing the concurrent processes and keeping the repetitions thesame, and testing that for different repetitions. That way a little grid search can bepreformed to find a weakness in the server. The results of this search are discussed inthe following sections. Note that a maximum of 500 clients could be tested by Siege,anything above that would result in a failure at server mangkus.

6.2 Results and Analysis

In the first series of tests the repetitions number is the same and the amount of concur-rent clients is changed. The amount of concurrency is displayed on the x-axis. Notethat it could be that a concurrent value that is tested is not been reached by the server.Concurrency means the amount of clients averagely served by the server for testing at acertain concurrent number. So 500 clients with 10 repetitions could mean that the serverdoes not reach a concurrent level of 500 clients. The reason is that the requests happensso fast that their is no point in time the server handles the full amount of clients that arerequesting data.

22




Figure 11: 10 repetitions, concurrency 10, 50, 100, 200, 300, 400, 500

See top left graph of figure 11. These results suggests that with 10 repetitions and arising number of concurrent clients the response time increases some what linearly. 100more clients can be roughly the same as an increase of response time of 0.1/0.2 seconds.

The throughput, top right graph, rises when the number of clients rises. This is a goodsign when talking about scalability. When the throughput rises when client numbersare rising it means that it can transfer more data when more clients are requesting data.

The transfer rate(left bottom graph) is the average number of requests that are handledper second. This rate does increase when more clients are requesting url’s but it stopsat 350.

The availability (right bottom graph) drops when concurrency increases. But it doesnot drop much. That is a positive and negative finding. When the amount of usersstarts to rise the availability needs to be 100%. A drop of 0.4% means that roughly 20requests (5000 ∗ 0.004) out of the 5000 requests in total, would not be answered. Thefact that it has a denial of service is worrying, but 0.4% is not drastic.

23



The same conclusion can be drawn concerning the response time. Notice that the lin-ear increase is roughly the same, but the concurrent clients are now more than in theprevious test. The Throughput is higher than in the previous test. This means that theserver’s bandwidth sends more MB/s when more clients are requesting data. It wouldbe interesting to see if this number would climb further.

The transfer rate rises more than with 10 repetitions. That means that there capable ofdealing with more clients.

The availability is lower than with 10 repetitions, a drop of 0.6% now means (2500∗0.08)200 requests that result in a failure. That is a higher than before.

24



The transfer rate rises more than with 10 repetitions. That means that there capable ofdealing with more clients. All the values stay roughly the same with as 50 repetitions.The walk of the availability graph looks the same as the one with 50 repetitions. Butnow (50000 ∗ 0.007) 350 requests are not answered.


25


It does not seem to matter how much repetitions are preformed by a certain number ofconcurrent clients. This suggests that the only weak spot of the server concerning theresponse time depends on how much clients at a time are demanding a request. It lookslike it does not matter how much repetitions those clients preform, it has no influenceon the response time. The throughput does rise when the amount of repetitions goup, but stops rising at around 440 connections. These results also suggest that a turn-ing point at between 200 and 300 concurrent clients exists, and the availability starts todrop. How much this would be when the amount of clients are doubled, is not clear atthis moment. What is more clear is that the response time at 400/500 clients sometimesgoes over the 1 second. Because the response time grows linearly with the amount ofclients, it suggests that when the amount of clients grow even larger, it will still climblinearly. That means the response time of a 1000 clients is around 2 seconds. Consider-ing that this an application that is only used for research, the number of clients wouldnot be 500 that are requesting at the same time. Above all, an average response timeof 0.1 second when a couple of clients are active is enough, when using the applicationwithout noticing any server delay.

7 Deployment

For installing the application to a device the sencha’s command line tool is used. Inthe root folder packager.json can be found. In this file the field for building theapplication has to changed. See below, listing 6.

Listing 6: packager.json

/∗∗∗ @cfg { S t r i n g } platform∗ @required∗ This i s the platform where you w i l l be running your a p p l i c a t i o n .∗ Avai lable opt ions are :∗ − iOSSimulator∗ − iOS∗ − Android∗ − AndroidEmulator

" platform " : " iOS " ,

Now by executing the command.

Listing 7: command to build native

$ sencha app build nat ive

The application is packaged. All the javascript code’s dependencies are resolved, mini-fied and placed in the build folder. The build contains two folders. One packageand one native folder. In the package folder the developer can see what result ofthe minification is, and can also test in the browser if everything still works. The nativefiles are placed in the native folder. When executing for Android the applicationsextension will be a .apk, for iOS it will be a .app file. The file can be transferred tothe device and installed. On Android it is easier that iOS. When building for Android

26


the result of the command(listing 7) runs the application when done with packaging.When building for iOS, sencha creates a .app file that can be transferred to the deviceby Itunes2.

The deployment can be distributed to other devices. On Android devices it’s possibleto install .apk files directly to the device from the command line. The generated .apk filecan also be distributed to other Android devices and can be installed without the useof the command line tool of Sencha Touch. For iOS this is more difficult. When a devel-oper is in the possession of an Apple’s developer account the UUID(Unique Identifier)needs to be added to the provisioning portal. This grants the device to install applica-tions that are also registered by the developers account. If the application only needsto tested on iOS, it is possible to jailbreak the iPad without need an Apple’s developeraccount. How to jailbreak the iPad to is desribed here http://greenpois0n.com/.For enabling to install without a developers account apps, “Appsync” has to be in-stalled.3

7.1 Get the app

The .apk and .ipa are located on github in the www/build/native folder.

$ g i t c lone git@github . com : i c y r i z a r d /FloodSimulation−Browser . g i t

Also the .apk and .ipa can be build from the code in the www folder.

8 Does Sencha Touch suffice

Sencha Touch 2 is used in this project for the cross-platform capabilities. One of theresearch question was to find the best tool to meet the requirement of cross-platform.Let’s start with the fact that everything works both on a Asus tf300t Transformer Padwith Android 4.0.3, iPad 2 with iOS 5.1.1 and the browsers Safari and Chrome. In Safariand Chrome the application runs smooth, all the animations and tap and drag are fast.The frame-rate of the animation stay the same high frame rate. Also on the iPad 2, ev-erything is smooth and fast and no problems occurred. Unfortunately the applicationon the Asus tf300t runs very slow. Scrolling through a list runs slow, changing fromthe cities list to the simulations list runs slow. Even the google maps object which ishas nothing to do with the implementation of Sencha Touch 2 or the F.S.B implemen-tation, runs slow. The frame rate of an animation is far less than on the iPad 2 and fornavigating through the map the same difference in speed is big.

An explanation for this can only be guessed. The first could be that the resolution of theAsus tf300t is higher than the iPad 2. 1280 * 800 resolution for the tf300t and a smaller1024 * 768. That is a difference 1024000 - 786432 = 237568 pixels.

2How to do this can be found in the video “Getting started” at: http://docs.sencha.com/touch/2-0/#!/guide/getting_started

3http://www.ijailbreak.com/cydia/install-cracked-apps-ios-5-0-1-with-appsync-installous/

27

http://greenpois0n.com/

http://docs.sencha.com/touch/2-0/#!/guide/getting_started

http://docs.sencha.com/touch/2-0/#!/guide/getting_started

http://www.ijailbreak.com/cydia/install-cracked-apps-ios-5-0-1-with-appsync-installous/


Because of the fact that both webkit browsers have similarly Javascript engines, Nitroon iOS and V8 on Android, the only thing that could effect the performance so much,would suggest a difference in another part of the rendering process. iOS renders CSSanimations via the GPU of the Phone. Although the new Android 4.0.3 supports hard-ware acceleration, it also has to be utilized by the browser. If it is the case and Android4.0.3 does not use the GPU for animations and iOS does, it could explain the drasticdifference in speed.

9 Conclusion

This thesis has described the process and requirements to create the F.S.B for tablets. Al-most all the problems have been tackled, the problems of the picking the best suitabletools. 1.The app’s design; 2. The communication with the API;3. Selecting simula-tions and the ability to play through them; 4. Creating image overlays of the imagesdelivered by the API; 5. Creating a chart of a certain area when the map is tappedand deploying it to both Android and iPad. That means that the application works ontablets, that have a native webkit browser. Although the final performance of SenchaTouch 2 on Android could be considered as the biggest drawback of this project, theapplication does work on Android. If it is due to a difference in resolution of the screenor an implementation of the native Android browser, meaning the rendering of CSSanimation via the GPU, the performance is a fact and cannot be denied. So it is possibleto create a cross-platform application that exists out of one code and can be build toboth Android and iPad.

The server scalability did good for a server that exists out of one physical system.When the number of clients rise to 500, the average response time rises above 1 sec-ond, which is acceptable. Judging from the fact that the response time rises linearlywith the amount of clients, if the amount of clients rises to 5000, the response time willbe around 10 seconds. Which is not an acceptable response time. An important thing tonote is that it did not seem to matter whether the clients fired 10, 50, 100 or 200 requests.The response time climbed the same way linearly. When talking about the availability,when the amount of clients rises above 200 clients, the requests start to fail. But thedrop in availability is so small that would be hardly noticeable.

The last findings about an intuitive design can not be fully answered. Whether or notthis application is intuitive, is not tested and is also difficult to test. In the apps design,the guide lines of Clark(2012) are taken in to account. The chances of the app is indeedintuitive is thereby enlarged, but proof of this fact is not available at this moment.

10 Discussion

In section 8 the issue “if Sencha Touch suffices the cross-platform demand” is discussedand the conclusion more or less was that it does the job wel but not animation/perfor-mance wise. More research has to be done to solve this animation issue to increasethe use-ability of this application. It well could be that the Mobile Browsers are not

28


all the same and do not fully support the today’s standards of HTML5 and CSS3. Atthis moment a future project can be at best natively programmed if performance is anissue. Another possibility could be Kivy [9] for android. Kivy makes it possible to useOpenGL [11] and multitouch gestures and program at a higher level in Python [13]. Butin this case the performance of the application on Android does the job and the perfor-mance is just more a convenience than a necessity. There are also a couple of things thatcould be improved in the application itself. For example, when the list of the individualsimulations is loaded, the image of the last simulation step is put in the image containerof that list item. This is an image only of the water, and is less informative than a sceen-shot with the exact location with the overlay image. This can be processed at serverside and a screenshot of the simulation with the map then would be available as a call-back by the API. If the google maps API would support a to take screenshot with thean overlay it would also be solved, but unfortunately this is not the case. Either way, ifthis is implemented in the application it would look a lot better. Also, the user can seewhere the simulation is done a lot faster, what than results in more intuitiveness.

Another improvement of the application would be that the Lsm data(population dy-namics) is seen together with the simulation. This is not possible at the moment, atclient side and at servers side. Because of the fact that there is no way of telling whichflood simulation corresponds to which lsm simulation. Nevertheless if this is possible,more knowledge about how a flood will influence the changes of survival in a certainarea is valuable data. Also more information can be given via the chart. The currentchart shows information about how much the cubic meters of water per time step flowsin that area, it only shows one line at a time. It would be nice to select a multitude ofplaces and see what the difference is between one area and another. This could be doneby placing a marker for every tap event and by deleting a certain marker, that this re-moves that data from the chart. In Sencha Touch this is not so easy to do, because theSencha API lacks in functionality to add and remove series on the fly. Therefore therewas no time left to accomplish this. But it would be a big extension of the application.A last point about the application’s shortcoming is already shortly discussed. The mapobject can be replaced by another map, for example OpenStreetMaps. This results in acomplete Open implementation of the application.

The scalability test on sangkil.science.uva.nl is another point that can be im-proved. The test can be expanded if the concurrent processes are more than 500. Thetest was limited due to errors in the mangkus server, when the tool Siege had to createmore than 500 concurrent clients. Nevertheless, it would be better to test the sangkilserver with a lot more clients. At 500 processes the server begins to have issues withavailability and response time. But what will happen when the number of clients raisesto 5000? Would the server perform worse and worse, or will it perform be the same.The results of the tests suggests that the response time climbs linearly, the throughputhas a limit of roughly 14MB/s, so transferring more and more data would not happendue to the bandwidth limit and the response time is estimated to grow more and more.

The application is now bound to the use of tablets, and can be locally executed byopening the index.html in the browser. This application could easily run on theserver but some minor changes have to be made. Simply of the fact that browsers blocka requests that is done on server A to a different server B, via Javascript. This is calledcross domain scripting. Browsers block these to prevent cross side scripting to take

29


place. A solution is, the JSONP [14] format. By simply telling the server to wrap afunction name(that the developer desides) around the JSON package, and than callingthat function, the problem is resolved.

The applications can now be used in the field. An Android or iPad can be taken to alocation and can be used to see what the effects of a dyke breach can be. Althoughthe simulations have to be done before hand, the user can take the tablet and go to thespecific place. From there the user can visually see what the best route of escape is,in the contrary to using the multi-touch table. Where all simulations are seen in-doorsand the plans are also made in-doors. This application is the first step towards a toolthat can be used in the field, with more improvements on the application itself, it wellcould be a perfect tool to aid the decision makers and ultimately bring the Urban Floodproject to a higher level.

30


References

[1] Actueel Hoogtebestand Nederland. http://www.ahn.nl/nieuws/ahn-2_data_0.

[2] Android information page. http://en.wikipedia.org/wiki/Google_Android.

[3] Appcelerator. http://www.appcelerator.com/.

[4] Check css3 support. http://www.caniuse.com/.

[5] Eclipse. http://www.eclipse.org/.

[6] HR Wallingford. http://www.hrwallingford.com/site/.

[7] iPad information page. http://en.wikipedia.org/wiki/IPad.

[8] jquery mobile. http://jquerymobile.com/.

[9] Kivy for android. http://kivy.org/docs/guide/android.html. Retrieved Juli 4,2012.

[10] Newsletter of urban flood workshop. http://www.urbanflood.eu/Pages/Newsletter2.aspx#interactive_flood_simulation.

[11] Opengl, the industry’s foundation for high performance graphics.http://www.opengl.org/.

[12] Phonegap. http://www.phonegap.com/.

[13] Python programming language. http://www.python.org/.

[14] Safer cross-domain ajax with json-p/jsonp. http://www.json-p.org/.

[15] Sdk wiki. http://en.wikipedia.org/wiki/Software_development_kit.

[16] Sencha touch. http://www.sencha.com/products/touch.

[17] UrbanFlood Project. http://www.urbanflood.eu/Pages/default.aspx.

[18] The webkit open source project. http://www.webkit.org/.

[19] Xcode. https://developer.apple.com/xcode/.

[20] CSS Wiki, 2012. http://en.wikipedia.org/wiki/Cascading_Style_Sheets.

[21] Bartosz Balis, Marek Kasztelnik, Marian Bubak, Tomasz Bartynski, TomaszBubala, Piotr Nowakowski, and Jeroen Broekhuijsen. The urbanflood commoninformation space. Procedia Computer Science, 4:96–105, 2011.

[22] A. Dallera. Why you should stay away from appcelera-tor titanium. http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/.

31

http://en.wikipedia.org/wiki/Google_Android

http://en.wikipedia.org/wiki/Google_Android

http://www.appcelerator.com/

http://www.caniuse.com/

http://www.eclipse.org/

http://www.hrwallingford.com/site/

http://en.wikipedia.org/wiki/IPad

http://jquerymobile.com/

http://www.urbanflood.eu/Pages/Newsletter2.aspx#interactive_flood_simulation

http://www.urbanflood.eu/Pages/Newsletter2.aspx#interactive_flood_simulation

http://www.phonegap.com/

http://www.json-p.org/

http://en.wikipedia.org/wiki/Software_development_kit

http://en.wikipedia.org/wiki/Software_development_kit

http://www.sencha.com/products/touch

http://www.urbanflood.eu/Pages/default.aspx

http://www.webkit.org/

https://developer.apple.com/xcode/

http://en.wikipedia.org/wiki/Cascading_Style_Sheets

http://en.wikipedia.org/wiki/Cascading_Style_Sheets

http://usingimho.wordpress.com/2011/06/14/

http://usingimho.wordpress.com/2011/06/14/

why-you-should-stay-away-from-appcelerators-titanium/


[23] Joe Dog. Siege. http://www.joedog.org/siege-home/.

[24] V.V. Krzhizhanovskaya, G.S. Shirshov, N.B. Melnikova, R.G. Belleman, F.I. Rusadi,B.J. Broekhuijsen, B.P. Gouldby, J. L’Homme, B. Balis, M. Bubak, A.L. Pyayt, I.I.Mokhov, A.V. Ozhigin, B. Lang, and R.J. Meijer. Flood early warning system:design, implementation and computational modules. Procedia Computer Science,4:106–115, 2011.

[25] A. Leff. Web-application development using the model/view/controller designpattern, 2001.

[26] Luis M. Vaguero, Luis Rodero-Merino, Jaun Caceres, and Maik Lindner. A breakin the clouds: towards a cloud definition. 39:50–55, 2009.

[27] W3C. Html 5, a vocabulary and associated apis for html and xhtml. RetrievedApril 11, 2012.

32

http://www.joedog.org/siege-home/


A Area API

# Terms

Map: d i g i t a l t e r r a i n map (DTM)P r o j e c t e d map : inundation map p r o j e c t e d /transformed to WGS84/EPSG:3857

( e . g . Google Maps) p r o j e c t i o n system

# Area L i s t

GET /area/ l i s t . j son

response :

{ " s t a t " : " ok " ," areas " : [

{ " area_id " : 1 ,"name " : " Sc ience Park " ," c e n t e r " : [ 5 2 . 3 4 7 1 8 5 , 4 . 9 3 7 0 8 8 5 ] ," corners " : [ [ 5 2 . 3 3 4 3 4 9 , 4 . 9 0 4 0 6 5 ] , [ 5 2 . 3 3 4 3 4 9 , 4 . 9 7 0 1 1 2 ] ,

[ 5 2 . 3 6 0 0 2 1 , 4 . 9 7 0 1 1 2 ] , [ 5 2 . 3 6 0 0 2 1 , 4 . 9 0 4 0 6 5 ] ] ," visbounds " : [52 .360021000000003 , 4 .9701120000000003 ,

52 .334349000000003 , 4 .9040650000000001] }

] }

note :

− " c e n t e r " i s the c e n t e r point coordinate of the map, in l a t i t u d eand longitude

− " corners " conta ins 4 p a i r s of numbers showing the WGS84 coordinate of thefour corners of the area , in l a t i t u d e and longi tude

− coordinates in the " corners " correspond to the coordinate ofthe lower l e f t , lower r ight , upper r ight , and upper l e f t cornersof the area , c o n s e c u t i v e l y

− " visbounds " conta ins 4 numbers represent ing the WGS84 coordinate ofnorth , east , south , west in l a t i t u d e or longi tude f o r lay ing out thep r o j e c t e d f looding image

# Area L i s t ( query )

GET /area/ l i s t . j son ?bounds=north , east , south , west

# Area Info

33


GET /area/<area_id >/i n f o . j son

response :

{ " s t a t " : " ok " ," area_id " : 1 ,"name " : " Sc ience Park " ," c e n t e r " : [ 5 2 . 3 4 7 1 8 5 , 4 . 9 3 7 0 8 8 5 ] ," corners " : [ [ 5 2 . 3 3 4 3 4 9 , 4 . 9 0 4 0 6 5 ] , [ 5 2 . 3 3 4 3 4 9 , 4 . 9 7 0 1 1 2 ] ,

[ 5 2 . 3 6 0 0 2 1 , 4 . 9 7 0 1 1 2 ] , [ 5 2 . 3 6 0 0 2 1 , 4 . 9 0 4 0 6 5 ] ] ," s i z e " : [ 8 8 0 , 5 6 5 ] ," e x t e n t s " : [ [ 0 , 0 ] , [ 0 , 0 ] ] ," p r o j e c t i o n " : " . . . " ," visbounds " : [52 .360021000000003 , 4 .9701120000000003 ,

52 .334349000000003 , 4 .9040650000000001] ," v i s s i z e " : [ 8 8 0 , 5 6 5 ] ," dikes " : [ [ [ l a t 1 , lng1 ] , [ l a t 2 , lng2 ] , [ l a t 3 , lng3 ] , [ l a t 4 , lng4 ] ] ,

[ [ l a t 5 , lng5 ] , [ l a t 6 , lng6 ] , [ l a t 7 , lng7 ] , [ l a t 8 , lng8 ] ] ]}

note :

− " corners " conta ins 4 p a i r s of numbers showing the WGS84 coordinate ofthe four corners of the area in l a t i t u d e and longitude

− " s i z e " shows width and height of the DTM and Inudation Zones Map− " c e n t e r " i s the c e n t e r point WGS84 coordinate of the map, in l a t i t u d e

and longitude− " e x t e n t s " conta ins 2 p a i r s of numbers showing the coordinate of

the lower l e f t and upper r i g h t corner of the map in i t s o r i g i n a lp r o j e c t i o n uni t

− " p r o j e c t i o n " conta ins p r o j e c t i o n parameter of the map in WKT format− " visbounds " conta ins 4 numbers represent ing the WGS84 coordinate of

north , east , south , west in l a t i t u d e or longi tude f o r lay ing out thep r o j e c t e d f looding image in t h i s area

− " v i s s i z e " i s the s i z e of p r o j e c t e d f looding image in t h i s area .Because of the p r o j e c t i o n , the f looding image may have d i f f e r e n t s i z ecompared to the o r i g i n a l DTM/Inundation Zones s i z e

− " dikes " conta ins a l i s t of c losed polygons descr ibed by a l i s t ofWGS84 coordinates which shows the region of the dikes in the area

# D i g i t a l Terra in Map

GET /area/<area_id >/topography . t x tGET /area/<area_id >/topography . t x t . gz

# Inundation Zones Map

GET /area/<area_id >/zones . t x t

34


GET /area/<area_id >/zones . t x t . gz

# Coordinate to Inundation Zone id mapping

GET /area/<area_id >/ i z i d . j son ? l a t l n g =<LAT>,<LNG>

response :

{ " s t a t " : " ok " ," area_id " : 1 ," l a t l n g " : [ 5 2 . 3 4 7 1 8 5 , 4 . 9 3 7 0 8 8 5 ] ," i z i d " : 12345}

35


B LSM

# I n t e r n a l API

# Input

POST /lsm/< t e s t _ i d >/input . xml

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# Resul t

POST /lsm/< t e s t _ i d >/ r e s u l t s /<filename >

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345 ,’ f i lename ’ : f i lename }

# S t a r t

POST /lsm/< t e s t _ i d >/+ s t a r t /

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# F in i sh

POST /lsm/< t e s t _ i d >/+ f i n i s h /

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# Error

POST /lsm/< t e s t _ i d >/+ e r r o r /

response :

{ ’ s t a t ’ : ’ ok ’ ,

36


’ t e s t _ i d ’ : 12345}

############################################################################ Publ ic API

# L i s t

GET /lsm/ l i s t . j son

response :

{ " s t a t " : " ok " ," s imulat ions " : [

{ " t e s t _ i d " : 1 , " area_id " : 1 ," submitted " : "2012−02−23 1 2 : 4 1 : 2 3 " } ,


] }

## V i s u a l i z a t i o n#

# V i s u a l i z a t i o n Info

GET /lsm/< t e s t _ i d >/ v i s u a l i z a t i o n / i n f o . j son

response :

{ " s t a t " : " ok " ," t e s t _ i d " : 12345 ," s i z e " : [ 8 8 0 , 5 6 5 ] ," types " : [ " paru " ]

}

notes :

− " s i z e " shows width and height of the DTM and Inudation Zones Mapof the area

− " types " shows v i s u a l i z a t i o n types i d e n t i f i e r t h a t are a v a i l a b l e

# V i s u a l i z a t i o n Images Info

GET /lsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/ i n f o . j son

response :

{ " s t a t " : " ok " ," s i z e " : [ 8 8 0 , 5 6 5 ] ,

37


" v i s s i z e " : [ 8 8 0 , 5 6 5 ] ," images " : [ 3 0 0 , 600]

}

note :

− " v is_ type " i s v i s u a l i z a t i o n type i d e n t i f i e r , t h i s corresponds to one ofthe value of " types " in V i s u a l i z a t i o n Info response

− " images " f i e l d conta ins l i s t of t imesteps of images t h a t haverendered completely .

− contents of " images " f i e l d are growing . I f the image has not beenrenderer , i t w i l l not be shown in the d i c t i o n a r y

− " v i s s i z e " i s the s i z e of p r o j e c t e d image

# V i s u a l i z a t i o n Image

GET /lsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/<timestep >. png

# P r o j e c t e d V i s u a l i z a t i o n Image

GET /lsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/map/<timestep >. png

38


C drfsm

# I n t e r n a l API

# S t a r t

POST /drfsm/< t e s t _ i d >/+ s t a r t /

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# F in i sh

POST /drfsm/< t e s t _ i d >/+ f i n i s h /

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# Error

POST /drfsm/< t e s t _ i d >/+ e r r o r /

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# Input

POST /drfsm/< t e s t _ i d >/input . xml

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345 ,’ area_id ’ : 2 }

# XMF

POST /drfsm/< t e s t _ i d >/ r e s u l t s /s imulat ion . xmf

response :

{ ’ s t a t ’ : ’ ok ’ ,

39


’ t e s t _ i d ’ : 12345}

# H5

POST /drfsm/< t e s t _ i d >/ r e s u l t s /s imulat ion . h5

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345}

# CSV

POST /drfsm/< t e s t _ i d >/ r e s u l t s /<timestep >. csv

response :

{ ’ s t a t ’ : ’ ok ’ ,’ t e s t _ i d ’ : 12345 ,’ t imestep ’ : 200}

############################################################################ Publ ic API

# Get input data

GET /drfsm/< t e s t _ i d >/input . xml

# Get r e s u l t

GET /drfsm/< t e s t _ i d >/ r e s u l t s /<timestep >. csv

# Simulat ion L i s t

GET /drfsm/ l i s t . j son

response :




] }

# Simulat ion L i s t ( d e t a i l vers ion )

40


GET /drfsm/ l i s t −d e t a i l . j son

response :


{ " t e s t _ i d " : 1 , " area_id " : 1 ," submitted " : "2011−06−23 1 2 : 4 1 : 2 3 " ," data " : {

" min_volume " : 100 ," max_volume " : 1000 ," min_level " : 20" max_level " : 200

} } ,{ " t e s t _ i d " : 2 , " area_id " : 1 ,

" submitted " : "2011−06−21 1 2 : 4 1 : 2 3 " ," data " : {


} }] }

The response i s s i m i l a r to the Simulat ion L i s t but with an a d d i t i o n a l " data "f i e l d t h a t conta ins data e x t r a c t e d from the r e s u l t .

# Simulat ion L i s t Summary

show summary ins tead of the l i s t

GET /drfsm/ l i s t . j son ?summary

response :

{ " s t a t " : " ok " ," t o t a l " : 100 , # t o t a l s imulat ions" s t a t u s " : {

"new " : 10 ," submitted " : 20 ," s t a r t e d " : 20 ," r e c e i v i n g " : 5 ," f i n i s h e d " : 55 ,

} ," submission " : [ < f i r s t submission date time > , < l a s t submission date time >] ," max_level " : [ <min> , <max> , <avg >] ," min_level " : [ <min> , <max> , <avg >] ,

41


" max_volume " : [ <min> , <max> , <avg >] ," min_volume " : [ <min> , <max> , <avg >] ,. . .

}

# Simulat ion L i s t ( query )

based on area

GET /drfsm/ l i s t . j son ? area_id=<area_id >GET /drfsm/ l i s t . j son ? area_id=<area_id_1 >,< area_id_2 > , . . .

based on water l e v e l ( l e v e l ) , water volume ( volume )

GET /drfsm/ l i s t . j son ? max_level =123 ( exac t )GET /drfsm/ l i s t . j son ? max_level =123 ,234 ( range )GET /drfsm/ l i s t . j son ? max_level =123 , (minimum)GET /drfsm/ l i s t . j son ? max_level = ,234 (maximum)

based on s t a t u s

GET /drfsm/ l i s t . j son ? s t a t u s = f i n i s h e d

note :

− combination ∗ should be∗ p o s s i b l e (FIXME , TODO)− "summary" query s t r i n g can a l s o be used to show the summary of f i l t e r e d l i s t

# Simulat ion Info

GET /drfsm/< t e s t _ i d >/i n f o . j son

response :

{ " s t a t " : " ok " ," s t a t u s " : " f i n i s h e d " ," t e s t _ i d " : 1 ," area_id " : 1 ," submitted " : "2011−06−24 1 0 : 0 0 : 0 0 " ," updated " : "2011−06−24 1 0 : 0 3 : 5 0 " ," rece ived " : [ . . . l i s t of t imesteps of r e s u l t s t h a t have been rece ived . . . ]" data " : {


}

42


}

note :

− the p o s s i b l e values of " s t a t u s " :− "new " : the s imulat ion has j u s t been submitted to the s e r v i c e− " submitted " : the s imulat ion has been submitted to the DRFSM t o o l− " r e c e i v i n g " : s imulat ion r e s u l t s are s t i l l being r e t r i e v e d− " f i n i s h e d " : a l l s imulat ion r e s u l t s are r e t r i e v e d

− the " data " f i e l d conta ins data r e t r i e v e d from the r e s u l t .I n i t i a l l y t h i s f i e l d i s empty and w i l l be f i l l e d once the data i s known .

############################################################################ Publ ic V i s u a l i z a t i o n API

# Screenshot

GET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n /screenshot . pngGET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n /screenshot −400x300 . png

# Info

GET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n / i n f o . j son

response :

{ " s t a t " : " ok " ," t e s t _ i d " : 1 ," s i z e " : [ 8 8 0 , 5 6 5 ] ," types " : [ " volume " , " l e v e l " ]

}

notes :

− " s i z e " shows width and height of the DTM and Inudation Zones Mapof the area

− " types " shows v i s u a l i z a t i o n types i d e n t i f i e r t h a t are a v a i l a b l e

# Image Info

GET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/ i n f o . j son

response :

{ " s t a t " : " ok " ," s i z e " : [ 8 8 0 , 5 6 5 ] ," v i s s i z e " : [ 8 8 0 , 5 6 5 ] ,

43


" images " : [ 3 0 0 , 600]}

note :

− " v is_ type " i s v i s u a l i z a t i o n type i d e n t i f i e r , t h i s corresponds to one ofthe value of " types " in V i s u a l i z a t i o n Info response

− " images " f i e l d conta ins l i s t of t imesteps of images t h a t haverendered completely .

− contents of " images " f i e l d are growing . I f the image has not beenrenderer , i t w i l l not be shown in the d i c t i o n a r y

− " v i s s i z e " i s the s i z e of p r o j e c t e d image

# Image

GET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/<timestep >. png

# P r o j e c t e d Image

GET /drfsm/< t e s t _ i d >/ v i s u a l i z a t i o n /<vis_type >/map/<timestep >. png

44

Date post:	26-Jun-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Bachelor Thesis - Flood Simulation BrowserBachelor Thesis - Flood Simulation Browser F.S.B. more...

Documents