Bachelor Thesis - Flood Simulation Browser

ubiquitousstrumpetMobile - Wireless

Dec 10, 2013 (3 years and 4 months ago)


Bachelor Thesis - Flood Simulation Browser
July 12,2012
Robert Belleman - U.v.A Richard Torenvliet
Bachelor Thesis - Flood Simulation Browser F.S.B.
1 Introduction 3
I Discovering the subject 4
2 Flood Simulation System 4
3 Flood Simulation App 5
3.1 Platformconsiderations............................5
3.1.1 Phonegap................................5
3.1.2 Overviewframeworks.........................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
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
Bachelor Thesis - Flood Simulation Browser F.S.B.
In this thesis we discuss the design and implementation of a cross platformap-
plication,designed specifically for tablets,that assists the UrbanFlood project in
making simulated flood more accessible for viewing simulations.This application
for viewing simulated floods was already available on a multi-touch table,which is
not easily transportable.To reach to goal of mobility,andto 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-platformap-
plication,but a more in-depth study showed that it could not fully live up to the
expectations.A second objective of the present study is to test how many clients
can be handled by the back end server at ones.Tests show that the response time
goes up considerably with the number of users,which shows that there are also
server 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 systemin Euro-
pean cities [17].In the today’s changing climate,more and more cities have to deal with
floods more often.An article of [24].A lot of research went in the possible solutions
for specific problems.Due to extreme rainfall,rising water or long lasting drought,the
instruments that protect the civilians of a certain area are negatively influenced.The
project involves setting up a systemthat can make estimates on howa levee would be-
have in the near future.Vigilance against weak spots in the levee is needed 24/7.To do
this they placed sensors in the levee that can be monitored remotely via internet.But
this 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 for
educative proposes.This subject is discussed in the present document.
This thesis concerns the Flood Simulation Browser.The concept of this browser is to
illustrate/visualize a flood in a particular area.With this technology people can see the
flowthat the water will take.When a dike breaks it is important to knowwhere the wa-
ter will flow.Information about which locations in the area will be under water first can
result 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 about
the risk of floods.The disadvantage of the multi touch table is that it is only accessible
in certain occasions.If the system were to be more accessible it makes it more likely
that someone with right authority can take better decisions about placing/reinforcing
a levee or creating evacuation plans.Moreover,if this systemis more accessible,civil-
ians of a certain area that is threatened by water,have the ability to gain knowledge of
where 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 a
solution has to be found.
Tablets are devices that support the same multi-touch gestures and are more accessible
than 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] and
Android [2] tablets.Users can take use of this application in an intuitive way,to get
Bachelor Thesis - Flood Simulation Browser F.S.B.
more intelligence about the complex situation at hand.They have the ability to choose
fromseveral 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 Android
is 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 how
much requests the server can handle at once it helps the urban flood project to estimate
how 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 to
knowthat an early warning systemstays online under the heavy load of a multitude of
This thesis covers the design choices that where made in order to reach those goal.The
first step is to get an idea of the existing simulation system this application will make
use of This includes a description of where this application is situated in the Urban
Flood Project as a whole.The study also includes an examination of the capabilities
of the different devices available,as well as a requirement analysis specifically for this
application.The resulting app will extend the simulation with a use-ability and above
all 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 and
intuitive 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 answer
the research questions.The second part describes the implementation,considering the
findings 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
The API is used by the client applications to get the appropriate data.The other is used
by API to create new simulations when a request at client side is made.The system
at 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
Bachelor Thesis - Flood Simulation Browser F.S.B.
this communcation system,which is also more widely used in the Early Warning Sys-
temto share information between different systems,e.g.monitoring data of the dikes
and the alarm(Attention Level Manager).The systems are needed for retrieving data
about a simulation and ultimately to display the simulations.The a GUI that
can display the simulations on a map.The simulations itself were made by the HR
Wallingford’s [6] simulation software and generated in the cloud [26].The simulations
can then be retrieved
The simulation programs of HR Wallingsford runs in the cloud.The cloud services are
running 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 to
generate.The flood simulation systemperforms 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 of
an 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 are
present on the machine.The important thing to note is that the final simulations are
images.These images are ready to be displayed on a map,e.g.Google Maps.Not only
does the systemhave the capability to calculate the flowof water,but it can also calcu-
late the estimated route that people take when a flooding takes place.It can calculate
how much people would survive a simulated flood,keeping in mind that this project
is all about saving people,this is interesting information.
3 Flood Simulation App
3.1 Platformconsiderations
3.1.1 Phonegap
As stated in the introduction the application is meant for tablets,but not specifically
for iOS or Android.Which means cross-platform.Howto maintain the cross-platform
demand on the application is one of the subjects of this project.This means that the
application is not a native implementation and consists of one code-base and runs on
more 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 and
PhoneGap can wrap this in an application.The native web-engine is used to render
the 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 previously
gained skills of webdevelopment can be re-used.Therefore there is no need to learn
a new programming language or sdk [15] for native apps.For example Objective C
for iOS and Java for Android.The disadvantage can be that the application feels more
like a mobile website than a real app.In addition,the end product depends on the
support of today’s web-standards.Not all browsers have full support for HTML5 and
CSS3,which forms the bases of a successful implementation of the application.For
a list of supported elements,websites like [4] can be used to determine
Bachelor Thesis - Flood Simulation Browser F.S.B.
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.
This solution is TitaniumMobile,the Appcelerator [3].TitaniumMobile can build mo-
bile applications that are in fact native applications.By programming in Javascript and
call functions to create native elements the application can be created.The framework
builds semi-native code,unlike the previously discussed PhoneGap.The development
for this platform is fast and an application for both iOS and Android are quickly off
the ground.But there is also a disadvantage to using Titanium.The applications are
big,around 11MB no matter what.Because of the fact that the logic will still be in
javascript(compiled),Titaniumhas to ship their javascript engine to the device.But not
only do Titanium generated apps take a lot of space,it also has trouble with memory.
This is partly fromown experience.The application is sometimes killed for no apparent
reason.With a little research on the web,I found that I was not the only one facing this
problem,see this blog-post [22].The blog-post discusses this issue,both developers
and users discuss this issue in the reactions.Although this blog post refers to version
1.6 and 2.0 is already out,we consider the uncertainty about this behaviour of Titanium
too great of a risk for the present project.
Developing and testing on iOS provides expected behaviour and a large part of native
elements are supported.But for Android the native elements are mostly not the ele-
ments you thought they would look like.To reach cross-platformapps,the developer
needs 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 advantage
if the project only meant to run on iOS.The idea of TitaniumMobile is great,it works
fine but will delay developing time when you truly want to reach crossplatform.Also
the fact that this application needs a map that supports overlays for the simulation im-
ages is a big disadvantage.By searching trough the documentation
,the only thing it
supports is adding an annotation.An annotation is just a marker placed on the map
with the ability to get de latitude and longitude of the marker.To sum up,Titanium
lacks support for both platform and map object,at the same time it can surprise the
developer in an unpleasant way by taking a lot storage and a buggy garbage collection.
Building crossplatformand creating native elements could mean a risk for completing
the application.Abrowser 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.
Bachelor Thesis - Flood Simulation Browser F.S.B.
Javascipt frameworks
As already explained,PhoneGap creates an app out of a website.This website can be
built in any way the developer likes,using web technologies supported on the native
device.There are frameworks that can speed up the development to make an intuitive
application.Two frameworks that are considered are:jQuery Mobile [8] and Sencha
Touch 2 [16].
jQuery Mobile This Javascript framework is build out of one Javascript file and one
CSS file that the developer includes.By giving certain HTML elements a data
attribute,which is a HTML5 element,the framework uses this to create views.A
page is made by declaring a div adding data-role="page".Such a page can be
given a footer like div data-role="footer".Switching frame one page to the
other 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 illustrate
the easy use of this frame work.Both pages have a button.Both buttons link to
the other page (foo,bar),so tapping on one button will change the page to the
other page.jQuery Mobile catches the requests that is made when a user taps on
a button.It then uses Ajax to handle the request and push the new page in the
Listing 1:jQuery Mobile,pages example
<div datar ol e ="page"i d=’ bar ’ >
<a#href =’ foo ’ datar ol e ="button">swi tch t o foo</a>
<div datar ol e =’ page ’ i d=’ foo ’ >
<a#href =’ bar ’ datar ol e ="button">swi tch t o bar </a>
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 but
with different information.The conclusion for jQuery mobile is that it is easy
and the developer does indeed use HTML5,CSS3 to create views.But it is not
easy to built a modular application.It is always possible to create such a modular
application 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 intended
Sencha Touch 2 Sencha touch 2 is a framework that is based on the Model ViewCon-
troller design pattern [25].It encourages the developer to use this pattern.The
way of developing really differs from jQuery mobile.Where jQuery mobile sets
you free to do whatever you like,Sencha Touch constraints the developer using
components 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 supported
by Sencha Touch like lists,a tabview,a map,etcetera.The difference between
jQuery and Sencha Touch is clearly noticable in the listings 1 and 2.
Bachelor Thesis - Flood Simulation Browser F.S.B.
A real convenience of the Sencha Touch 2 framework,provides a command-line
tool to build a starting environment.It creates files where the developer can start
from.It is recommended to use this as a starting point.The advantage is an
application that is structured out of the box with a design pattern that is a well
known 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 with
the command line tool of sencha.Testing for Android and iOS became much
more 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 fromthe command-line is a lot easier than running both
Adisadvantage of Sencha Touch couldbe,as seen in listing 2,the syntax of Sencha
Touch is not so easy at first.So the learning curve could be very steep.The last
argument that has a great influence on deciding which framework to use,could
be 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 the
multi-touch table has this feature.It would be a great extension of the project if
this was possible.So with an eye on the future it could save a lot trouble,and it
could 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.appl i cat i on ( {
name:’ foo ’,
launch:f unct i on ( ) { eat e ("",{
f ul l s c r een:true,
i tems:[
t i t l e:’ bar ’,
i conCl s:’ bar ’,
html:’ bar ’
} );
} );
Bachelor Thesis - Flood Simulation Browser F.S.B.
3.1.2 Overviewframeworks
The following table is an overviewof the previously discussed properties of tools;Tita-
nium,jQuery Mobile in combination with Phonegap and Sencha Touch.
+ is positive,- is negative,– strong negative,++ strongly positive
supported comp.
dev time

jQuery Mobile

Sencha Touch 2
Sencha Touch 2 has the most positive signs based on the previous sections.Therefore
the platformSencha 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.The
application needs components for interaction and displaying of data.The components
are 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 by
cities.The corresponding simulations have to be retrieved from the server and
displayed in a list.Those list-items are the individual simulations,so it makes
sense that when tapping on a list item,the simulation of the related itemis going
to be displayed.
Map The formof these simulations are important.The simulations are in the formof
images.These images are images from above and can be placed on the map.In
order to display these images,there has to be a map available.This is the most
important 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 images
that are placed on the map.Arequirement for these simulation images is that the
user 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 viewport
when the user has tapped on a list itemof a simulation.
Chart The flood simulations contain information about howmuch water is present in
a certain timestep in a specific location.This information needs to be displayed
in such a way that it can be interpreted by the user.This requires a chart with the
timesteps on the x-axis and another value like volume on the y-axis.To determine
the zone which contains the information,latitude and longitude information is
needed again.
Simulation’s Switcher Next to flood simulation,also population dynamics simula-
tions are available.Therefore controls are needed to change the simulation type.
Bachelor Thesis - Flood Simulation Browser F.S.B.
These simulations also have a location and time steps,so the same map can be
used to display these simulations.
These requirements are taken in to account in the applications design.The next section
will 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 tablets
the screen is larger than on mobile phones.Which can result in a bigger travel distance
of the user’s hands.The GUI design has to be built with the considerations of the
interaction capability of the users.For instance,unlike with mobile phones,according
to Clark(2012) a leading designer in creating multi-touch applications,people tend to
hold a tablet on the top halve of the tablet when holding with both hands,Figure 1.
The focus of the user is going fromtop to bottom.The top elements of the application
will draw the first attention of the user.That’s why Clark(2012) advises to place the
important controls on the top half of the view.The components that are important have
to 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 a
list of cities.The list is scrollable and can be seen as an"infinite"array of cities around
the world.Every city has its own array of simulations to show.It therefore makes sense
to also showthese in a list.When a city is selected,the user has no use of the capability
Bachelor Thesis - Flood Simulation Browser F.S.B.
to select other cities and its simulations.That’s why the list of cities are pushed out of
the viewport and the list of simulations is pushed in.It also makes sense to have one
Map object in the view,where one city (latitude,longitude) can be shown at a time.The
mapobject is the most important component of the F.S.B.andtherefore takes the biggest
space.It also makes it easier to pan and zoomthe map.The list component where cities
and simulations are placed is at the left side of the view.It could also be the right side
but it would not matter.Since two hands are more or less symmetrical,so placing the
list 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 simulation
consists of multiple images on different time steps.By giving the user control of which
image is seen at which time step is a crucial feature in the browser.Since the list is
placed in on the left side of the screen,the controls appear in the right top part of the
screen.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 new
simulations to be simulated in the cloud.The spot of the simulation can be arbitrary
on the map,by simply touching a place on the map and alter some parameters,the
cloud service calculates a new simulation.Although this feature can be an seen as an
extension of my project,with time left this feature can be build in.That’s why it can be
discussed in the App’s design.The controls of these parameters need to be somewhere
in view,by placing this in the neighbourhood where the user touches the map could be
intuitive.However,this should never happen when the user is just navigating over the
map,the user has to know that if he or she is the mode of with picking a place where
to create a newsimulation.
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 that
area 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
Bachelor Thesis - Flood Simulation Browser F.S.B.
Figure 3:When Amsterdam is selected,the map moves the center of the map to Amsterdam.In this
screenshot,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 server
address is test this server it is required to exclude
any other parameter of the client.That way,the maximum values of the server are
tested and not the limitations of the client.To get these values,the server mangkus.,that is located in the same network as
nl,is used for testing.The servers have the exact same specifications,so this is ideal for
testing the maximumvalues of,this is not a realistic test
Bachelor Thesis - Flood Simulation Browser F.S.B.
but it is meant to find the maximum values.For stress testing the server a tool called
siege [23] is used.With this tool it is possible to launch requests to a url with n-nodes
and 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 -
 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 newinsight can be provided.By increasing the number of simultaneous
connections,values could start to change.To really give the server a stress test,it is
possible to provide a list of urls which can randomly be picked and executed.This
simulates a more likely scenario and provides more insight on how the server would
behave in a real situation.The expectation is that the response time might growas the
number of clients starts to grow.With more clients to serve,it could take longer if there
are more clients active.If processor power is limited,maximum available memory is
reached or even the implementation of the server for handling requests could all have
an effect in the response time,or any other variable.The research for which variables
changes,together with the cause and the solution is a part of this project and will be
documented in the end report.
End of Part one
Part I describes the questions and some answers on what the approach of tackling this
problemis going to be.For an understanding of what global problems are faced in this
project,it will be sufficient to have read part one.Part II holds information about how
the implementation is made,the problems that where discovered in process,results
are 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,git@
Bachelor Thesis - Flood Simulation Browser F.S.B.
Part II
Implementation Details
4 Server API
Aclear 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 referenced
in the appendix A,B and C.The appendix is referenced and used for explanations in
the following sections.
5 Sencha Touch 2
The final choice for the development of this application was made in favor of Sencha
Touch 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 described
in that section.
Sencha Touch is based on MVCwith the addition of stores.Stores can hold information
of whatever the application needs,more about this in a moment.The model is used
for the communication with the database,the controller stands between the model and
the view.The controller can steer between views and handle logic.The application has
no direct need of models,since there is no database that has to be updated.Stores can
handle 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 en
simulationslist.Alist object is defined as follows.
Bachelor Thesis - Flood Simulation Browser F.S.B.
st or e = eat e ( ’ ’ {
f i e l ds:[ ’ name’,’ corners ’,’ visbounds ’,’ area_i d ’,’ cent er ’,’ si ze ’ ],
type:’ rest ’,
url:’ ht t p://sangki l.sci i s t.j son ’,
type:’ j son ’,
root Propert y:’ areas ’
} ); eat e ( ’ Ext.Li st ’,{
t i t l e:’ l ocat i ons ’,
st or e:’ c i t ys t or 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 fields
are available in the list,containing the name of the field between brackets { },the
field name of record n is placed in list itemn.Five stores are present in the application.
 SimulationStore.js
Is insync with
on the server.Locally the store is in sync with the viewList.js.Basically this
store returns information of the simulation locations that are available.The most
important data are the name,center,visbounds and area_id.With the name for
displaying 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.The
visbounds are used to scale the image on the tiled map,it contains the lat,lng
information of the south west and north east locations of the square.When the
user taps on a list-item,the data of longitude and latitude information is used to
change the center of the map and push a newlist over the current list,since a tap
event on a list-item returns the tapped item and the store used for creating this
list.The second list holds information about which all the simulations available.
 FloodDetailStore.js
Is insync withmultiple urls,
<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 the
SimulationStore.js.The dikes consists of eight values,which are 4 corners with
Bachelor Thesis - Flood Simulation Browser F.S.B.
a latitude and longitude value.This means that a polygon can be formed from
these four locations and displayed on the map.
 LsmDetailStore.js
This store holds information of the population dynamics,meaning howthe evac-
uation of the individuals will proceed.
 SimulationSummary.js
Syncs with
summary.This returns a JSON string that holds a list of all the simulations.A
store 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 stay
present,so before doing anything the store has to be cleared of all the filters.
 ChartStore.js
This store is used for creating the chart.The chart expects a jsonStore with data
and fields to plot.The data is retrieved fromthe 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 easy
to create.Alayout keyword is placed in the Container component which functions as a
container 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 the
developer likes.Alayout in this application is used once in app/view/main.js.
Bachelor Thesis - Flood Simulation Browser F.S.B.
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.Flex
1 or flex 2 tells the container on which side of the container the components needs
to situated.See 8 for how these are used to as a reference.The image of figure 7 is
implemented in figure 8.
Ext.def i ne ("app.view.Main",{
extend:’ Ext.Container ’,
conf i g:{
t i t l e:"Si mul ati on Browser",
l ayout:"hbox",
f ul l s c r een:true,
i tems:[
xtype:’ l i s t panel ’,
f l ex:1,
xtype:’ si mul ati onpanel ’,
f l ex:2
} ],
} );
Figure 8:Layout in app/view/Main.js
The xtype keyword matches the keyword out of the component where the xtype is
defined.It serves as shortcut to the full component.Components that are created can
get a unique xtype value and be referred to by other components to call functions or for
displaying of that component,this is widely used throughout the application.
Bachelor Thesis - Flood Simulation Browser F.S.B.
5.3 Controllers
Controllers performthe 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 vieware created in the ref attribute in the config
attribute.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().Controllers
are declared like the following.
Ext.def i ne ( ’ app.c ont r ol l er.Main ’,{
extend:’ rol l er ’,
conf i g:{
r ef s:{
cont r ol:{
tappedButton:f unct i on ( ) {
t hi s.getMap ( ).dofuncti on ( );
} );
In the application two controllers exists,a app/controller/main.js controller for
handling logic for the general viewand simulations.Another controller named
app/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 the
viewwhen the right event is passed.And when the viewneeds more data than stores
can 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 viewand extending
Since Sencha Touch 2 became available Google Maps is a build-in type.Because of the
way the map is really an instance of the google maps api.I decided to let the Map
viewextend that api,and let the controller call those functions just like it would when
it talks to the google maps api.This choice is made not only done for convenience
but the ability to create multiple controllers to talk to the same map would be a bigger
advantage than placing this in a separate controller.Also by initiating a map that is
based on another tiled map object like open street view that uses the same function
names.Aquick change between different maps could be established.
Amap object is declared like the following.
Bachelor Thesis - Flood Simulation Browser F.S.B.
Ext.def i ne ( ’ app.view.Map’,{
i d:’ mapa’,
xtype:’ SimulationMap ’,
conf i g:{
func:f unct i on ( ) {
} );
In the application the Map object extends and uses the Google API.Overlays are used
for placing simulations images on the map.When the maprender event is fired,it
returns a reference to the Google API and Ext Map component.The Google Maps
API specified in the documentation is used for creating overlays and adding markers
on a certain Lat,Lng.The most important feature is initializing the first image by
calling createOverlayImage function when a simulation is tapped in the list and
creating overlays for the rest of the timesteps.These images are stepped through in the
nextImage and prevImage function.Which are controlled when a button in the control
panel is tapped.
5.5 Controls
The controls to change the simulation step when a simulation is selected,appears in
the right top of the screen.The component has four controls;forward,backwards,play
forward,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 button
plays through the simulation automatically.The left and bottom button both do the
opposite.Also a pause button stops calling the next or prevImage function out the map
object.As previously discussed,the controls appear in the right top of the screen.If the
user needs the controls on the bottompart of the screen,the user can also tap and drag
the controls.Because the space of the tablet is limited the user can make the decision of
Bachelor Thesis - Flood Simulation Browser F.S.B.
placing the controls somewhere else,note that the controls are constrained to the right
side of the screen.The reason is that the controls are meant to be used by the user’s
right hand.
5.6 Chart Display
The chart data is displayed when the user taps on a simulation image on the map.The
google maps API supports the click event,the event has a payload where the latitude
and longitude data can be obtained.Amarker 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??for
the requests.
Listing 3:requests for flood data
/ obt ai n i zi d /
ht t p://sangki l.sci<area_i d>/i zi d.j son?l at l ng=
<l at >,<lng>
/ obt ai n csv f i l e /
ht t p://sangki l.sci<t est _i d >/r es ul t s/i zi d/<i zi d >.csv
Aresponse looks like the following.
Listing 4:csv response
time,i zi d,volume,l evel,di schargex,di schargey
The first value is the time step of the simulation,the third is the volume.The chart will
display the volume (in cubic meters) on the y-axis and the time steps on the x-axis.By
simply splitting on a","and placing the value at position 0 and position 2 of every line
except line 0,in a separate array and feed in to ChartStore.js,as discribed in section
5.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 means
that the panel with the chart can be placed in the viewat a certain position.In the items
array,xytpe:’chart’ is placed,Sencha now knows what kind of component to place
inside the Ext.Panel.The chart itself has a couple of fields that are necessary in order to
plot the data.First of all the name of the jsonStore,
Listing 5:Chart component app/view/Chart.js
Ext.def i ne ( ’ app.view.Chart ’,{
extend:’ Ext.Panel ’,
i d:’ floodchart ’,
xtype:’ floodChart ’,
requi r es:[ ’ ’ ],
conf i g:[ {
Bachelor Thesis - Flood Simulation Browser F.S.B.
i tems:[ {
xtype:’ chart ’,
st or e:’ chart St ore ’,
type:’ Numeric ’,
posi t i on:’ l e f t ’,
f i e l ds:[ ’ volume ’ ]
type:’ Category ’,
posi t i on:’ bottom’,
f i e l ds:[ ’ Time Steps ’ ]
s e r i es:[ {
type:’ l i ne ’,
xFi el d:[ ’ time ’ ],
yFi el d:[ ’ volume ’ ],
} ],
} ]
} ]
} ):
The series attribute in the Chart configuration means what kind of plots are going to
displayed.So it is possible to create more series and display different types of data
in the chart.Also because the chart can be fairly large,this component is also made
draggable for the user to create more space.
Figure 10:The chart in the final application
Bachelor Thesis - Flood Simulation Browser F.S.B.
6 Scalability
The server is tested on scalability.The server specifica-
tions are two Intel(R) Xeon(R) CPUE5620 @2.40GHz processors,with both 4 cores and
8 threats and 23GiB of memory.An important part to notice when testing a server is
how well it performs depending on the number of peers it is serving.By looking at
how the response time will change if the number of clients increases,can tell how the
rate of scalability.The number of clients a server can serve simultaneously is of course
the number 1 issue in scalability.So howdo the values change when connections,and
therefore client numbers,start to rise.
To test the server,all bottlenecks at client side have to be brought down to a minimum. is the address of another server with the same specifica-
tions.The mangkus server is situated in the same server rack as sangkil,and has
the exact same specifications.The TCP/IP packages do not have to travel around the
world in order to reach the destination,so the response time when not in a stress test
could be in optimumstate.
6.1 Testing
So testing the sangkil server is done fromthe server mangkus.A tool siege is used for
testing the server,previously discussed in section 3.4 in part one.
$ si ege i b f f i l e.t xt c $1 r $2
i randomly pi cki ng request out of f i l e.t xt
b no delay between the next request a c l i e nt does
c concurrent processes
r number of r epet i t i ons
Testing is done by changing the concurrent processes and keeping the repetitions the
same,and testing that for different repetitions.That way a little grid search can be
preformed to find a weakness in the server.The results of this search are discussed in
the 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.Note
that 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 a
certain concurrent number.So 500 clients with 10 repetitions could mean that the server
does not reach a concurrent level of 500 clients.The reason is that the requests happens
so fast that their is no point in time the server handles the full amount of clients that are
requesting data.
Bachelor Thesis - Flood Simulation Browser F.S.B.
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 a
rising number of concurrent clients the response time increases some what linearly.100
more 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 good
sign when talking about scalability.When the throughput rises when client numbers
are rising it means that it can transfer more data when more clients are requesting data.
The transfer rate(left bottomgraph) is the average number of requests that are handled
per second.This rate does increase when more clients are requesting url’s but it stops
at 350.
The availability (right bottom graph) drops when concurrency increases.But it does
not drop much.That is a positive and negative finding.When the amount of users
starts to rise the availability needs to be 100%.A drop of 0.4% means that roughly 20
requests (5000  0:004) out of the 5000 requests in total,would not be answered.The
fact that it has a denial of service is worrying,but 0.4%is not drastic.
Bachelor Thesis - Flood Simulation Browser F.S.B.
Figure 12:50 repetitions,concurrency 10,50,100,200,300,400,500
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 the
previous test.The Throughput is higher than in the previous test.This means that the
server’s bandwidth sends more MB/s when more clients are requesting data.It would
be interesting to see if this number would climb further.
The transfer rate rises more than with 10 repetitions.That means that there capable of
dealing with more clients.
The availability is lower than with 10 repetitions,a drop of 0.6%nowmeans (25000:08)
200 requests that result in a failure.That is a higher than before.
Bachelor Thesis - Flood Simulation Browser F.S.B.
Figure 13:100 repetitions,concurrency 10,50,100,200,300,400,500
The transfer rate rises more than with 10 repetitions.That means that there capable of
dealing 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.But
now(50000  0:007) 350 requests are not answered.
Figure 14:200 repetitions,concurrency 10,50,100,200,300,400,500
Bachelor Thesis - Flood Simulation Browser F.S.B.
It does not seemto matter howmuch repetitions are preformed by a certain number of
concurrent clients.This suggests that the only weak spot of the server concerning the
response time depends on howmuch clients at a time are demanding a request.It looks
like it does not matter how much repetitions those clients preform,it has no influence
on the response time.The throughput does rise when the amount of repetitions go
up,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 to
drop.Howmuch this would be when the amount of clients are doubled,is not clear at
this moment.What is more clear is that the response time at 400/500 clients sometimes
goes over the 1 second.Because the response time grows linearly with the amount of
clients,it suggests that when the amount of clients grow even larger,it will still climb
linearly.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 would
not be 500 that are requesting at the same time.Above all,an average response time
of 0.1 second when a couple of clients are active is enough,when using the application
without noticing any server delay.
7 Deployment
For installing the application to a device the sencha’s command line tool is used.In
the root folder packager.json can be found.In this file the field for building the
application has to changed.See below,listing 6.
Listing 6:packager.json
 @cfg { St r i ng } pl atform
 @required
 Thi s i s the pl atform where you wi l l be running your appl i cat i on.
 Avai l abl e opt i ons are:
  iOSSimulator
  iOS
  Android
  AndroidEmulator
"pl atform":"iOS",
Nowby executing the command.
Listing 7:command to build native
$ sencha app bui l d nat i ve
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 package
and one native folder.In the package folder the developer can see what result of
the minification is,and can also test in the browser if everything still works.The native
files are placed in the native folder.When executing for Android the applications
extension will be a.apk,for iOS it will be file.The file can be transferred to
the device and installed.On Android it is easier that iOS.When building for Android
Bachelor Thesis - Flood Simulation Browser F.S.B.
the result of the command(listing 7) runs the application when done with packaging.
When building for iOS,sencha creates file that can be transferred to the device
by Itunes
The deployment can be distributed to other devices.On Android devices it’s possible
to install.apk files directly to the device fromthe command line.The generated.apk file
can also be distributed to other Android devices and can be installed without the use
of 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 needs
to tested on iOS,it is possible to jailbreak the iPad without need an Apple’s developer
account.Howto jailbreak the iPad to is desribed here
For enabling to install without a developers account apps,“Appsync” has to be in-
7.1 Get the app
The.apk and.ipa are located on github in the www/build/native folder.
$ gi t cl one gi t@gi cyr i zar d/FloodSimulation t
Also the.apk and.ipa can be build fromthe 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 the
research 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 Pad
with Android 4.0.3,iPad 2 with iOS 5.1.1 and the browsers Safari and Chrome.In Safari
and 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 application
on the Asus tf300t runs very slow.Scrolling through a list runs slow,changing from
the cities list to the simulations list runs slow.Even the google maps object which is
has 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 for
navigating 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 the
Asus tf300t is higher than the iPad 2.1280 * 800 resolution for the tf300t and a smaller
1024 * 768.That is a difference 1024000 - 786432 = 237568 pixels.
Howto do this can be found in the video “Getting started” at:
Bachelor Thesis - Flood Simulation Browser F.S.B.
Because of the fact that both webkit browsers have similarly Javascript engines,Nitro
on 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 CSS
animations via the GPUof the Phone.Although the newAndroid 4.0.3 supports hard-
ware acceleration,it also has to be utilized by the browser.If it is the case and Android
4.0.3 does not use the GPU for animations and iOS does,it could explain the drastic
difference 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 suitable
tools.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 images
delivered by the API;5.Creating a chart of a certain area when the map is tapped
and deploying it to both Android and iPad.That means that the application works on
tablets,that have a native webkit browser.Although the final performance of Sencha
Touch 2 on Android could be considered as the biggest drawback of this project,the
application does work on Android.If it is due to a difference in resolution of the screen
or an implementation of the native Android browser,meaning the rendering of CSS
animation via the GPU,the performance is a fact and cannot be denied.So it is possible
to create a cross-platform application that exists out of one code and can be build to
both 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 linearly
with the amount of clients,if the amount of clients rises to 5000,the response time will
be around 10 seconds.Which is not an acceptable response time.An important thing to
note is that it did not seemto 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 the
drop in availability is so small that would be hardly noticeable.
The last findings about an intuitive design can not be fully answered.Whether or not
this 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 indeed
intuitive 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-platformdemand” is discussed
and 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 increase
the use-ability of this application.It well could be that the Mobile Browsers are not
Bachelor Thesis - Flood Simulation Browser F.S.B.
all the same and do not fully support the today’s standards of HTML5 and CSS3.At
this moment a future project can be at best natively programmed if performance is an
issue.Another possibility could be Kivy [9] for android.Kivy makes it possible to use
OpenGL [11] and multitouch gestures and programat a higher level in Python [13].But
in 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 that
could be improved in the application itself.For example,when the list of the individual
simulations is loaded,the image of the last simulation step is put in the image container
of 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 server
side 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 the
an overlay it would also be solved,but unfortunately this is not the case.Either way,if
this is implemented in the application it would look a lot better.Also,the user can see
where 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,at
client side and at servers side.Because of the fact that there is no way of telling which
flood simulation corresponds to which lsmsimulation.Nevertheless if this is possible,
more knowledge about how a flood will influence the changes of survival in a certain
area is valuable data.Also more information can be given via the chart.The current
chart shows information about howmuch the cubic meters of water per time step flows
in that area,it only shows one line at a time.It would be nice to select a multitude of
places and see what the difference is between one area and another.This could be done
by placing a marker for every tap event and by deleting a certain marker,that this re-
moves that data fromthe chart.In Sencha Touch this is not so easy to do,because the
Sencha API lacks in functionality to add and remove series on the fly.Therefore there
was no time left to accomplish this.But it would be a big extension of the application.
Alast point about the application’s shortcoming is already shortly discussed.The map
object can be replaced by another map,for example OpenStreetMaps.This results in a
complete Open implementation of the application.
The scalability test on is another point that can be im-
proved.The test can be expanded if the concurrent processes are more than 500.The
test was limited due to errors in the mangkus server,when the tool Siege had to create
more than 500 concurrent clients.Nevertheless,it would be better to test the sangkil
server with a lot more clients.At 500 processes the server begins to have issues with
availability and response time.But what will happen when the number of clients raises
to 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 throughput
has a limit of roughly 14MB/s,so transferring more and more data would not happen
due to the bandwidth limit and the response time is estimated to growmore and more.
The application is now bound to the use of tablets,and can be locally executed by
opening the index.html in the browser.This application could easily run on the
server but some minor changes have to be made.Simply of the fact that browsers block
a requests that is done on server A to a different server B,via Javascript.This is called
cross domain scripting.Browsers block these to prevent cross side scripting to take
Bachelor Thesis - Flood Simulation Browser F.S.B.
place.A solution is,the JSONP [14] format.By simply telling the server to wrap a
function name(that the developer desides) around the JSONpackage,and than calling
that function,the problemis resolved.
The applications can now be used in the field.An Android or iPad can be taken to a
location and can be used to see what the effects of a dyke breach can be.Although
the simulations have to be done before hand,the user can take the tablet and go to the
specific 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-doors
and the plans are also made in-doors.This application is the first step towards a tool
that can be used in the field,with more improvements on the application itself,it well
could be a perfect tool to aid the decision makers and ultimately bring the Urban Flood
project to a higher level.
Bachelor Thesis - Flood Simulation Browser F.S.B.
[1] Actueel Hoogtebestand Nederland.
[2] Android information page.
[3] Appcelerator.
[4] Check css3 support.
[5] Eclipse.
[6] HR Wallingford.
[7] iPad information page.
[8] jquery mobile.
[9] Kivy for android. Juli 4,
[10] Newsletter of urban flood workshop.
[11] Opengl,the industry’s foundation for high performance graphics.
[12] Phonegap.
[13] Python programming language.
[14] Safer cross-domain ajax with json-p/jsonp.
[15] Sdk wiki.
[16] Sencha touch.
[17] UrbanFlood Project.
[18] The webkit open source project.
[19] Xcode.
[20] CSS Wiki,2012.
[21] Bartosz Balis,Marek Kasztelnik,Marian Bubak,Tomasz Bartynski,Tomasz
Bubala,Piotr Nowakowski,and Jeroen Broekhuijsen.The urbanflood common
information space.Procedia Computer Science,4:96–105,2011.
[22] A.Dallera.Why you should stay away from appcelera-
tor titanium.
Bachelor Thesis - Flood Simulation Browser F.S.B.
[23] Joe Dog.Siege.
[24] V.V.Krzhizhanovskaya,G.S.Shirshov,N.B.Melnikova,R.G.Belleman,F.I.Rusadi,
Mokhov,A.V.Ozhigin,B.Lang,and R.J.Meijer.Flood early warning system:
design,implementation and computational modules.Procedia Computer Science,
[25] A.Leff.Web-application development using the model/view/controller design
[26] Luis M.Vaguero,Luis Rodero-Merino,Jaun Caceres,and Maik Lindner.A break
in the clouds:towards a cloud definition.39:50–55,2009.
[27] W3C.Html 5,a vocabulary and associated apis for html and xhtml.Retrieved
April 11,2012.
Bachelor Thesis - Flood Simulation Browser F.S.B.
A Area API
Map:di gi t a l t er r ai n map (DTM)
Proj ect ed map:i nundati on map proj ect ed/transformed t o WGS84/EPSG:3857
( e.g.Google Maps) pr oj ect i on system
#Area Li s t
GET/area/l i s t.j son
{"s t at":"ok",
{"area_i d":1,
"name":"Sci ence Park",
"cent er":[ 52.347185,4.9370885],
"corners":[ [ 52.334349,4.904065],[ 52.334349,4.970112],
[ 52.360021,4.970112],[ 52.360021,4.904065] ],
"visbounds":[ 52.360021000000003,4.9701120000000003,
52.334349000000003,4.9040650000000001] }
] }
"cent er"i s the cent er poi nt coordi nat e of the map,i n l at i t ude
and l ongi t ude
"corners"cont ai ns 4 pai r s of numbers showing the WGS84 coordi nat e of the
four corners of the area,i n l at i t ude and l ongi t ude
 coordi nat es i n the"corners"correspond t o the coordi nat e of
the lower l e f t,lower ri ght,upper ri ght,and upper l e f t corners
of the area,consecut i vel y
"visbounds"cont ai ns 4 numbers represent i ng the WGS84 coordi nat e of
north,east,south,west i n l at i t ude or l ongi t ude f or l ayi ng out the
proj ect ed f l oodi ng image
#Area Li s t ( query )
GET/area/l i s t.j son?bounds=north,east,south,west
#Area I nf o
Bachelor Thesis - Flood Simulation Browser F.S.B.
GET/area/<area_i d>/i nf o.j son
{"s t at":"ok",
"area_i d":1,
"name":"Sci ence Park",
"cent er":[ 52.347185,4.9370885],
"corners":[ [ 52.334349,4.904065],[ 52.334349,4.970112],
[ 52.360021,4.970112],[ 52.360021,4.904065] ],
"s i ze":[ 880,565],
"ext ent s":[ [ 0,0],[ 0,0] ],
"pr oj ect i on":"...",
"visbounds":[ 52.360021000000003,4.9701120000000003,
"vi s s i ze":[ 880,565],
"di kes":[ [ [ l at 1,lng1 ],[ l at 2,lng2 ],[ l at 3,lng3 ],[ l at 4,lng4 ] ],
[ [ l at 5,lng5 ],[ l at 6,lng6 ],[ l at 7,lng7 ],[ l at 8,lng8 ] ] ]
"corners"cont ai ns 4 pai r s of numbers showing the WGS84 coordi nat e of
the four corners of the area i n l at i t ude and l ongi t ude
"s i ze"shows width and hei ght of the DTM and Inudati on Zones Map
"cent er"i s the cent er poi nt WGS84 coordi nat e of the map,i n l at i t ude
and l ongi t ude
"ext ent s"cont ai ns 2 pai r s of numbers showing the coordi nat e of
the lower l e f t and upper r i ght corner of the map i n i t s or i gi nal
pr oj ect i on uni t
"pr oj ect i on"cont ai ns pr oj ect i on parameter of the map i n WKT format
"visbounds"cont ai ns 4 numbers represent i ng the WGS84 coordi nat e of
north,east,south,west i n l at i t ude or l ongi t ude f or l ayi ng out the
proj ect ed f l oodi ng image i n t hi s area
"vi s s i ze"i s the s i ze of proj ect ed f l oodi ng image i n t hi s area.
Because of the proj ect i on,the f l oodi ng image may have di f f er ent s i ze
compared t o the or i gi nal DTM/Inundation Zones s i ze
"di kes"cont ai ns a l i s t of cl osed polygons descri bed by a l i s t of
WGS84 coordi nat es which shows the regi on of the di kes i n the area
#Di gi t al Terrai n Map
GET/area/<area_i d>/topography.t xt
GET/area/<area_i d>/topography.t xt.gz
#Inundation Zones Map
GET/area/<area_i d>/zones.t xt
Bachelor Thesis - Flood Simulation Browser F.S.B.
GET/area/<area_i d>/zones.t xt.gz
#Coordinate t o Inundation Zone i d mapping
GET/area/<area_i d>/i zi d.j son?l at l ng=<LAT>,<LNG>
{"s t at":"ok",
"area_i d":1,
"l at l ng":[ 52.347185,4.9370885],
"i zi d":12345}
Bachelor Thesis - Flood Simulation Browser F.S.B.
#I nt er nal API
POST/lsm/<t est _i d >/i nput.xml
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
#Resul t
POST/lsm/<t est _i d >/r es ul t s/<fil ename >
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345,
’ filename ’:fi l ename }
#St ar t
POST/lsm/<t est _i d >/+s t a r t/
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
#Fi ni sh
POST/lsm/<t est _i d >/+f i ni s h/
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
POST/lsm/<t est _i d >/+er r or/
{ ’ st at ’:’ ok ’,
Bachelor Thesis - Flood Simulation Browser F.S.B.
’ t est _i d ’:12345}
#Publ i c API
#Li s t
GET/lsm/l i s t.j son
{"s t at":"ok",
"si mul at i ons":[
{"t es t _i d":1,"area_i d":1,
"submitted":"20120223 12:41:23"},
{"t es t _i d":2,"area_i d":1,
"submitted":"20120221 12:41:23"},
] }
#Vi sual i zat i on
#Vi sual i zat i on I nf o
GET/lsm/<t est _i d >/vi s ual i zat i on/i nf o.j son
{"s t at":"ok",
"t es t _i d":12345,
"s i ze":[ 880,565],
not es:
"s i ze"shows width and hei ght of the DTM and Inudati on Zones Map
of the area
"types"shows vi s ual i zat i on types i de nt i f i e r t hat are avai l abl e
#Vi sual i zat i on Images I nf o
GET/lsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/i nf o.j son
{"s t at":"ok",
"s i ze":[ 880,565],
Bachelor Thesis - Flood Simulation Browser F.S.B.
"vi s s i ze":[ 880,565],
"images":[ 300,600]
"vi s_t ype"i s vi s ual i zat i on type i de nt i f i e r,t hi s corresponds t o one of
the value of"types"i n Vi sual i zat i on I nf o response
"images"f i e l d cont ai ns l i s t of t i mest eps of images t hat have
rendered compl etel y.
 cont ent s of"images"f i e l d are growing.I f the image has not been
renderer,i t wi l l not be shown i n the di ct i onar y
"vi s s i ze"i s the s i ze of proj ect ed image
#Vi sual i zat i on Image
GET/lsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/<ti mestep >.png
#Proj ect ed Vi sual i zat i on Image
GET/lsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/map/<ti mestep >.png
Bachelor Thesis - Flood Simulation Browser F.S.B.
C drfsm
#I nt er nal API
#St ar t
POST/drfsm/<t est _i d >/+s t a r t/
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
#Fi ni sh
POST/drfsm/<t est _i d >/+f i ni s h/
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
POST/drfsm/<t est _i d >/+er r or/
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
POST/drfsm/<t est _i d >/i nput.xml
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345,
’ area_i d ’:2}
POST/drfsm/<t est _i d >/r es ul t s/si mul at i on.xmf
{ ’ st at ’:’ ok ’,
Bachelor Thesis - Flood Simulation Browser F.S.B.
’ t est _i d ’:12345}
POST/drfsm/<t est _i d >/r es ul t s/si mul at i on.h5
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345}
POST/drfsm/<t est _i d >/r es ul t s/<ti mestep >.csv
{ ’ st at ’:’ ok ’,
’ t est _i d ’:12345,
’ ti mestep ’:200}
#Publ i c API
#Get i nput data
GET/drfsm/<t est _i d >/i nput.xml
#Get r es ul t
GET/drfsm/<t est _i d >/r es ul t s/<ti mestep >.csv
#Si mul ati on Li s t
GET/drfsm/l i s t.j son
{"s t at":"ok",
"si mul at i ons":[
{"t es t _i d":1,"area_i d":1,
"submitted":"20110623 12:41:23"},
{"t es t _i d":2,"area_i d":1,
"submitted":"20110621 12:41:23"},
] }
#Si mul ati on Li s t ( det ai l versi on )
Bachelor Thesis - Flood Simulation Browser F.S.B.
GET/drfsm/l i s t det ai l.j son
{"s t at":"ok",
"si mul at i ons":[
{"t es t _i d":1,"area_i d":1,
"submitted":"20110623 12:41:23",
"mi n_l evel":20
} },
{"t es t _i d":2,"area_i d":1,
"submitted":"20110621 12:41:23",
"mi n_l evel":20
} }
] }
The response i s s i mi l ar t o the Si mul ati on Li s t but with an addi t i onal"data"
f i e l d t hat cont ai ns data ext r act ed from the r es ul t.
#Si mul ati on Li s t Summary
show summary i nst ead of the l i s t
GET/drfsm/l i s t.j son?summary
{"s t at":"ok",
"t ot a l":100,#t ot a l si mul at i ons
"s t at us":{
"s t ar t ed":20,
"r ecei vi ng":5,
"f i ni shed":55,
"submission":[ < f i r s t submission date time >,<l a s t submission date time >],
"max_level":[ <min>,<max>,<avg >],
"mi n_l evel":[ <min>,<max>,<avg >],
Bachelor Thesis - Flood Simulation Browser F.S.B.
"max_volume":[ <min>,<max>,<avg >],
"min_volume":[ <min>,<max>,<avg >],
#Si mul ati on Li s t ( query )
based on area
GET/drfsm/l i s t.j son?area_i d=<area_i d >
GET/drfsm/l i s t.j son?area_i d=<area_i d_1 >,<area_i d_2 >,...
based on water l evel ( l evel ),water volume ( volume )
GET/drfsm/l i s t.j son?max_level =123 ( exact )
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 at us
GET/drfsm/l i s t.j son?s t at us=f i ni shed
 combination should be possi bl e ( FIXME,TODO)
"summary"query s t r i ng can al so be used t o show the summary of f i l t e r e d l i s t
#Si mul ati on I nf o
GET/drfsm/<t est _i d >/i nf o.j son
{"s t at":"ok",
"s t at us":"f i ni shed",
"t es t _i d":1,
"area_i d":1,
"submitted":"20110624 10:00:00",
"updated":"20110624 10:03:50",
"recei ved":[...l i s t of t i mest eps of r es ul t s t hat have been recei ved...]
"mi n_l evel":20
Bachelor Thesis - Flood Simulation Browser F.S.B.
 the possi bl e val ues of"s t at us":
"new":the si mul at i on has j us t been submitted t o the s er vi ce
"submitted":the si mul at i on has been submitted t o the DRFSM t ool
"r ecei vi ng":si mul at i on r es ul t s are s t i l l being r et r i eved
"f i ni shed":a l l si mul at i on r es ul t s are r et r i eved
 the"data"f i e l d cont ai ns data r et r i eved from the r es ul t.
I n i t i a l l y t hi s f i e l d i s empty and wi l l be f i l l e d once the data i s known.
#Publ i c Vi sual i zat i on API
GET/drfsm/<t est _i d >/vi s ual i zat i on/screenshot.png
GET/drfsm/<t est _i d >/vi s ual i zat i on/screenshot 400x300.png
#I nf o
GET/drfsm/<t est _i d >/vi s ual i zat i on/i nf o.j son
{"s t at":"ok",
"t es t _i d":1,
"s i ze":[ 880,565],
"types":["volume","l evel"]
not es:
"s i ze"shows width and hei ght of the DTM and Inudati on Zones Map
of the area
"types"shows vi s ual i zat i on types i de nt i f i e r t hat are avai l abl e
#Image I nf o
GET/drfsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/i nf o.j son
{"s t at":"ok",
"s i ze":[ 880,565],
"vi s s i ze":[ 880,565],
Bachelor Thesis - Flood Simulation Browser F.S.B.
"images":[ 300,600]
"vi s_t ype"i s vi s ual i zat i on type i de nt i f i e r,t hi s corresponds t o one of
the value of"types"i n Vi sual i zat i on I nf o response
"images"f i e l d cont ai ns l i s t of t i mest eps of images t hat have
rendered compl etel y.
 cont ent s of"images"f i e l d are growing.I f the image has not been
renderer,i t wi l l not be shown i n the di ct i onar y
"vi s s i ze"i s the s i ze of proj ect ed image
GET/drfsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/<ti mestep >.png
#Proj ect ed Image
GET/drfsm/<t est _i d >/vi s ual i zat i on/<vi s_type >/map/<ti mestep >.png