Skip to content

F
FloodSimulation-Browser
Commit 398ca70b authored by icyrizard's avatar icyrizard
Browse files
Options

plot works

parent af88fa74
Hide whitespace changes
Inline Side-by-side
Showing with 366 additions and 212 deletions
docs/proposal/Makefile 0 → 100644
View file @ 398ca70b
# default:
# rm -f *.aux *.toc *.log *.out *.pdf
# pdflatex proposel.tex
# bibtex proposel.aux
# pdflatex proposel.tex
# pdflatex proposel.tex
proposel.tex: title.tex fsb.tex
%.pdf: %.tex
pdflatex $^
pdflatex $^
%.bbl: %.bib
pdflatex $(^:.bib=.tex)
bibtex8 $(@:.bbl=.aux)
pdflatex $(^:.bib=.tex)
pdflatex $(^:.bib=.tex)
clean:
rm -f *.aux *.toc *.log *.out
realclean:
rm -f *.aux *.toc *.log *.out *.pdf
docs/proposal/fsb.tex
View file @ 398ca70b
\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{listings}
\usepackage{graphicx}
\author{Richard Torenvliet - 6138861}
\title{Flood Simulation Browser}
\begin{document}
\maketitle
%\documentclass[10pt,a4paper]{article}
%\usepackage[utf8]{inputenc}
%\usepackage{amsmath}
%\usepackage{amsfonts}
%\usepackage{amssymb}
%\usepackage{listings}
%\usepackage{graphicx}
%\author{Richard Torenvliet - 6138861}
%\title{Flood Simulation Browser}
%\maketitle
\section{Introduction}
This project 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 flow that the water will take. When a dike breaks it is important to know where the water will flow and at which time-step. Information about which locations in the area will be under water first can result in a successful evacuation plan. This system already exists but this project involves taking advantage of this system and make it easier available and accessible. Which makes it more likely that someone with the right authority can take decisions about placing dikes and creating a successful early warning system.
The implementation of this application will be on a multi-touch device. In particular iPad and Android tablets. Users can use this application in an intuitive way and get more intelligence about the complex situation at hand. They have the ability to choose from several simulations that where already made for a specific area and also creating new ones.
This document covers design choices/options in order to reach that goal. The first step is to get an idea of the existing simulation system of which this application will take use of. This includes a clarification of which part of the system this Browser will take. The next step will be finding what out the requirements of the tablet implementation, like what features does it have to contain in order to be to maintain the intuitiveness. Just by showing the data would not be sufficient. The function of this App is to extend the simulation system with a use-ability factor.
A side assignment of this project is testing the scalability of the REST server. By testing how much requests the server can handle at ones it helps the urban flood project to estimate how much people can use the application at ones. The original multi touch application on the multi touch table was only only one client. It's important to know that an early warning system stays online under the pressure of al lot of clients.
This project 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 flow that the water will take. When a dike breaks it is important to know where the water 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, but is build for a multi-touch table only and is accessible by few people. This project aims on making it easier available and accessible. Which makes it more likely that someone with the right authority can take decisions about placing/reinforcing dikes or creating evacuation plans. Moreover, if this system is more accessible, then civilians of a certain neighbourhood that is threatened by water, have the ability to take 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 hour of need.
The implementation will be on a multi-touch device. In particular iPad and Android tablets. Users can use this application in an intuitive way and get more intelligence about the complex situation at hand. They have the ability to choose from several simulations that were already made for a specific area and also creating new simulations.
This document covers design choices/options in order to reach that goal. The first step is to get an idea of the existing simulation system of which this application will take use of. This includes a clarification of where this application is situated in the Urban Flood Project as a whole. The next step will be finding out the requirements of the tablet implementation, like which features does it have to contain in order to maintain intuitiveness. Just by showing the data would not be sufficient. The function of this App is to extend the simulation system with a use-ability factor.
A side assignment of this project is testing the scalability of the REST server. By testing how much requests the server can handle at ones it helps the urban flood project to estimate how many users can use the application at ones. The original multi touch application on the multi touch table was only one client. It's important to know that an early warning system stays online under the pressure more of clients.
The scientific research of this project will be the research for an intuitive design. The question will be, where do buttons, lists, and other important components need to be situated in an application. An other aspect of this project is the research for scalability of the server. This data will provide information about how many users can be handled by a server at once will be the question. The last subject of this research will be the decision of which framework or tool to use for the implementation of this application.
\section{Flood Simulation System}
The system that already exists runs in the Cloud. That means it does all the calculation for the client and it is not important to know at which physical computer it runs. The system can calculate other simulation by providing parameters about a certain area. When a simulation is run it will be stored in the system. With other calls the system returns a set of simulation that are present in the current database. Now the important thing to note is that the simulation consists of images that have to be displayed on a map, let's say Google Maps. The flood simulation system preforms a complex simulation with the height map of the area. The height map consists of detailed information about the height of an area. With this data the flow of the water can be calculated and turned in to images.
The simulation system already exists and runs in the Cloud. That means it does all the calculation for the client and it's not important to know at which physical computer it runs. The system can calculate simulations by providing parameters about a certain area. For instance, the location and how much water you want to simulate. When a simulation is submitted and calculated, the simulation is stored. With calls the system it returns a set of simulations that are present. The important thing to note is that the simulation consists of images that have to be displayed on a map, let's say Google Maps. The flood simulation system performs a complex simulation with the height map of the area. The height map holds detailed information about the height of an area. With this data, the flow of the water can be calculated and turned in to images. These images are used by the client application, this an important part of this project.
Not only does the system calculates the flow of water but it also calculates the estimated route that people take. 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.
\subsection{Flood API}
The API is a REST api that returns a JSON formatted string. It's a client server system where requests are done by the client and the appropriate data is transferred back to the client. With this data, information about a certain simulation can be displayed.
The API is a REST api that return JSON formatted string. It's a client server system where requests are done by the client and the appropriate data is transferred back to the client. With this data, information about a certain simulation can be displayed. The data can be in the form of an image or information in .csv files. The .csv files can be plotted and displayed in as a chart or graph.
\subsection{Scalability}
A side assignment of the project is to test the scalability of the server. The server address is sangkil.science.uva.nl. To test this server it is needed to exclude any other parameter of the client. Such as maximum download speed, maximum throughput, latency of the network that the testing is finding place. The idea is not to test this at a home pc, but test it in a server that is hooked up in the same network as sangkil.science.uva.nl. If this is the case the exclusion of restricted variables at client side is possible.
For stress testing the server there is a tool available called siege\footnote{http://www.joedog.org/siege-home/}. With this tool it is possible to launch request to a url with n-nodes with k fire-ing connections per second. Siege registers the following data:
A side assignment of the project is to test the scalability of the server. The server address is \url{sangkil.science.uva.nl}. To test this server it is needed to exclude any other parameter of the client. Such as maximum download speed, maximum throughput, latency of the network. The idea is not to test this at a home pc, but test it in a server that is hooked up in the same network as sangkil.science.uva.nl. If this is the case the exclusion of restricted variables at client side could be possible.
For stress testing the server a tool called siege \cite{Siege} would be of assistance. 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:
\begin{itemize}
\item Transmissions - total
\item Transactions - total hits
\item Availability - percentage of total succeeded hits
\item Elapsed Time - seconds
\item Data Transfer - (MB/s)
\item Response Time -
\item Transfer Rate
\item Throughput
\item Concurrent
\item OKAY,
\item Failed
\item Data Transferred - MB
\item Response Time - seconds
\item Transaction Rate - seconds
\item Throughput - MB/s
\item Concurrency - rate of concurrency
\item Succesful transaction - number of succeeded hits
\item Failed transactions - number of failed hits
\item Longest transaction - seconds
\item Shortest transaction - seconds
\end{itemize}
With this data new insight can be provided. By increasing the number of simultaneous connections, values could start to change. The expectations are that the response time might be longer. 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 the implementation of the server for handling requests could effect in the response time.
With this data new insight can be provided. By increasing the number of simultaneous connections, values could start to change. To really give the server a stress test, it's 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 grow as 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.
\section{Flood Simulation App}
\subsection{Platform considerations}
As stated in the introduction the app is meant for tablets, but not specific for iOS or Android. How can we maintain this demand on the application? Is one of the research question. This means that the application is not native programmed but consists of one code-base and runs on more devices. There is a technology called PhoneGap that uses HTML5 CSS 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 that used to render the mobile website. PhoneGap can result in a huge speed-up in development which is a huge advantage because of the skills gained by webdevelopment can be re-used. Therefore there is no need to learn a new programming environment used for native apps in Objective C with Xcode for iOS and Java with Eclipse for Android. The advantage that is easy to learn and re-using earlier experiences in web development can be re-used, the disadvantage can be that it feels like a mobile website in stead of a native application. Luckily frameworks exists where native-like elements are created for you.
As stated in the introduction the app is meant for tablets, but not specific for iOS or Android. How to maintain this 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 \cite{PhoneGap} that uses HTML5, CSS3 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 for native apps. For example Objective C for iOS and Java for Android. The disadvantage can be that it feels like a mobile website in stead of a native application. 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 caniuse.com \cite{CSS3} can be used to determine the percentage of support for a certain element/feature. But does not solve anything. Nevertheless, one disadvantage can be solved, a native feel of an application. For example, frameworks where native-like elements are created for you while coding in a programming language already known by a webdeveloper also exists.
This solution is Titanium Mobile, the Appcelerator \cite{Titanium-Appcelerator}. Titanium Mobile can build mobile 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, in the contrary to previously discussed PhoneGap. The development for this platform is fast and an application for both iOS and Android are quickly of the ground. But there is also a disadvantage by using Titanium. The applications are big, around 11MB no matter what. Because of the fact that the logic will still be in javascript(compiled), Titanium has to ship their javascript engine to the device. But not only do they take a lot of space on the storage device, it also has trouble with memory, see this blog-post\cite{memoryleak}. 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, it's a threat to this project that can pop-up unexpectedly.
This can be a Titanium Mobile, the Appcelerator. Titanium Mobile can build mobile applications that are in fact native applications. By programming in Javascript and call functions to create native elements. The framework builds native code, in contrary to previously discussed PhoneGap. The development for this platform is fast and an application for both iOS and Android are quickly of the ground. But there is also a disadvantage by using Titanium. The applications are big, around 11MB no matter what. Not only is do they take a lot of space on the storage device, but also has trouble of memory leaks(link). Developing and testing on iOS provides expected behaviour and a lot is possible, for Android the native elements are mostly not the elements you thought the look like. To reach cross-platform apps you need to constantly check if your building an element for iOS or for Android. It might be stated that the functionalities of the platforms are randomly picked from the API. The idea of Titanium Mobile is great, it works fine but will delay developing time when you truly want to reach crossplatform.
Moreover developing and testing on iOS provides expected behaviour and a large part of native elements are supported, for Android the native elements are mostly \textbf{not} the elements you thought they would looked like. To reach cross-platform apps 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 supported. iOS is far out the most supported platform. Which only provides an advantage if the project only meant to run for iOS. The idea of Titanium Mobile is great, it works fine but will delay developing time when you truly want to reach crossplatform.
\subsubsection*{Javascipt frameworks}
As already explained, PhoneGap only provides the possibility to create an app out of a website. This website can be build in any way the developer likes using webtechnologies supported on the native device. There are frameworks that can speed up the development to make an intuitive application. Two frameworks that can be considered jQuery Mobile and Sencha Touch.
As already explained, PhoneGap only provides the possibility to create an app out of a website. This website can be build 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 \cite{jQuery-Mobile} and Sencha Touch \cite{sencha}.
\begin{description}
\item [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 a href to an id of a page. The next example will result in two pages, the 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.
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 a href to an id of a page. The figure \ref{fig:jquery} provides an example that will result in two pages, 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.
\begin{figure}
\begin{lstlisting}
<div data-role="page" id='bar'>
<a #href='foo' data-role="button">switch to foo</a>
</div>
<div data-role='page' id='foo'>
<a #href='bar' data-role="button">switch to bar</a>
</div>
\end{lstlisting}
\caption{jQuery Mobile, pages example}
\label{fig:jquery}
\end{figure}
Creating to pages are quickly made, the downside of jQuery mobile is that in order to create an application where views look a like, you have to repeat yourself. You have to create pages with other id's but with the same The conclusion is that jQuery mobile is really easy and the developer does indeed use html, css to create views. But it is not easy to build a modular application. It is always possible to create such a modular application yourself, but when creating an application which is not such a framework the developer will run in to creating a framework in stead of the intended application.
Creating two pages is quickly done, the downside of jQuery mobile is that in order to create an application where views look a like, 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 is that jQuery mobile is that it is easy and the developer does indeed use HTML, CSS to create views. But it is not easy to build a modular application. It is always possible to create such a modular application yourself, but when creating an application which is not such a framework the developer will run in to creating a framework in stead of the intended application.
\item [Sencha Touch 2]
Sencha touch 2 is a framework focused on the Model View Controller design pattern. It encourages the developer to use this pattern. The way of developing really differs from jQuery mobile. There 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 explained with an example.
In the items array, see figure \ref{fig:sencha}, the items in that array can be anything supported by sencha touch like lists, a tabview, a map, etcetera.
Sencha touch provides a command-line tool to build a starting environment. It creates files where the developer can start from. It's 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 the current standard(MVC). With Sencha Touch 2 there is no need for PhoneGap, unlike jQuery Mobile. Sencha Touch 2 provides the possibility to run the code on your simulator or native device with the command line tool. Testing for Android an iOS became much more simplistic resulting in less developing time. Running PhoneGap for Android, needs Eclipse to build, for iOS the developer needs to build in Xcode. When testing on both devices the developer needs to be able to test in both environments, and testing from the command-line is a lot easier than running both environments.
A disadvantage of Sencha Touch could be, as seen in figure ~\ref{fig:sencha}, 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. The next section will discuss this in more detail.
\begin{figure}[h!]
\begin{lstlisting}
Ext.application({
......@@ -87,27 +100,47 @@ Ext.application({
}
});
\end{lstlisting}
\caption{Sencha Touch application example. This example creates an application with the name 'foo'. The html can be placed inside the items array. }
\label{fig:sencha}
\caption{Sencha Touch application example}
This example creates an application with the name 'foo'. The html can be placed inside the items array.
\end{figure}
\end{description}
In the items array in the example there but other items like lists, tabview or a map. And items are configured with the config attribute. Any component present in the sencha touch framework. The advantage is an application that is structured out of the box with a design pattern that is current standard(MVC). With sencha touch 2 there is no need for PhoneGap, unlike jQuery Mobile. Sencha Touch 2 provides the possibility to run the code on your simulator or native device by the command line tool. Testing for Android an iOS became much more simplistic resulting in less developing time. Running PhoneGap for Android needs Eclipse to build, on iOS you need to build in the Xcode. When testing on both devices you'll need to be able to test in both environments which is highly less desirable than building from command line. A disadvantage of sencha touch could be, as seen in figure \ref{fig:sencha}, the syntax of sencha touch is not so easy at first. So the learing curve could be very .
\subsection{App Design}
The application will be used on tablets so a lot of space can be used. Working with tablets the screen gets larger than mobile phones. Which can result in a bigger travel distance of the user's hands. The GUI design has to be build 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 intend to hold a tablet on the top halve of the tablet when holding with both hands, figure \ref{fig:perimeter}. The focus of the user is going from top to down. 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 screen. The components that are important have to be placed in the left or right top of the screen. By taking Clark's advise the Flood Simulation Browser can be inspired.
First of all the flood simulations are within different cities. This can typically be a list of cities, also a list is scrollable and can be seen as an infinite array of cities around the world. Every city has it's own array of simulations to show. So it makes sense to also show these in a second list. When a city is selected, the user has no use of the capability to select other cities and it's simulations. This is because it makes sense to only have one Map object in the view where one location (latitude, longitude) can be shown at a time. The map object is the component that is the important part of the browser. Inspired by Clark(2012) it can be stated that a hierarchy in importance of different view components can result in a different place on the screen. By placing the Map component always in the view and also as the biggest component the idea of placing objects in a hierarchy of importance in the view is considered.
The list component where cities and simulations are placed is the left side of the view, it could also be the right side but it would not matter. 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, but which controls shown in the top bar is not clear at this moment. Controls that would be needed is the ability to change the image placed on the map. 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.
The flood simulation browser already build 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 can create a new simulation to be seen. 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 considered in the App's design. The controls of these parameters need to be somewhere in view, by placing this in the neighbourhood of the place where the user placed touched the map could be intuitive. But not if happens when your only are browsing through the map, the user has to know that it is in the mode of with picking a place where to create a new simulation. The specification about these controls are discussed in the end report.
\begin{figure}[h!]
\subsection{App Design}
The application will be used on tablets so a lot of space can be used. Working with tablets the screen gets larger than mobile phones. Which can result in a bigger travel distance of the user's hands. The GUI design has to be build 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 intend to hold a tablet on the top halve of the tablet when holding with both hands, figure \ref{fig:perimeter}. The focus of the user is going from top to down. 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 screen. The components that are important have to be placed in the left or right top of the screen. By taking Clark's advise the Flood Simulation Browser can be inspired.
\begin{figure}[ht]
\center
\includegraphics[scale=0.3]{touch.png}
\caption{Portrait touch perimeter(Clark, 2012)}
\label{fig:perimeter}
\end{figure}
First of all the flood simulations are within different cities. This can typically be a list of cities, also a list is scrollable and can be seen as an "infinite" array of cities around the world. Every city has it's own array of simulations to show. So it makes sense to also show these in a list. When a city is selected, the user has no use of the capability to select other cities and it's 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 map object is the most important component of the browser. Inspired by Clark(2012) it can be stated that a hierarchy in importance of different view components can result in a different place on the screen. By placing the Map component always in the view and also as the biggest component, the idea of placing objects in a hierarchy of importance in the view is considered. For an example of this, see figure \ref{fig:mockup}.
The list component where cities and simulations are placed is 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. Which controls shown in the top bar is not clear at this moment. Controls to change the image placed on the map 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. Where and when(on which event) to place these controls is discussed in the final document.
\begin{figure}[ht]
\center
\begin{tabular}{c}
\includegraphics[scale=0.2]{mockup1.png} \\
\includegraphics[scale=0.2]{mockup2.png}
\end{tabular}
\label{fig:mockup}
\caption{Cities list of which simulations are available}
\end{figure}
\begin{figure}[ht]
\includegraphics[scale=0.5]{chart.png} \\
\caption{Example of sencha chart}
\label{fig:sencha chart}
\end{figure}
The flood simulation browser that is already build 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 can create a new simulation to be seen. 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 considered 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. But not if it happens when the user is just navigating over the map, the user has to know that it is in the mode of with picking a place where to create a new simulation. The specification about these controls are discussed in the end report.
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. The API requests latitude, longitude values, it then returns data of a location that is closest to this point. The application needs to display this data in a clear and understandable way. Charts are great way to display this data. In development of this application there needs to be a clear understanding of what usability is. Only displaying a chart of certain values could not be enough to learn anything or draw conclusions about the flood. The goal is to make use of the Sencha Touch Chart framework in order to provide comprehensive data of a flood in a certain area. See figure \label{fig:sencha chart} for an example of the chart framework.
\pagebreak
\section{Conclusion}
The project will be implemented with the framework Sencha Touch 2. All encountered issues will be discussed in the end report. This information can be used in future projects relating to creating cross-platform applications. Also all data about the scalability of the server will be documented. The urban flood project can in turn use this data in future plans to invest in more server power. If they do not need to invest in more power this is also important.
This project will ultimately result in a cross-platform application that can be used by the public or government to gain information about a certain area.
%http://www.netmagazine.com/features/designing-touch John Clark 2012 on February 01, 2012
\end{document}
\ No newline at end of file
docs/proposal/proposel.tex 0 → 100644
View file @ 398ca70b
\documentclass[a4paper, 11pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[margin=2.5cm, nohead]{geometry}
\usepackage{palatino, url, multicol}
\usepackage{amssymb, graphicx, fancyhdr, latexsym, url, verbatim}
\usepackage{algorithm, algorithmic}
\usepackage{hyperref}
%\usepackage{natbib}
\usepackage[all]{xy}
\usepackage{listings}
\usepackage{cite}
\usepackage[english]{babel}
\usepackage[font=small,format=plain,labelfont=bf,up,textfont=it,up]{caption}
\usepackage{xspace}
%\usepackage{subfigure} % has to be loaded after caption to prevent clash Commented, because subfig is the newer (and presumably
% better) version of subfigure...
\usepackage{subfig}
\usepackage{xcolor}
%\usepackage[titles,subfigure]{tocloft}
%
%
%\setlength{\cftbeforesecskip}{0.1cm}
\newcommand{\todo}[1]{\colorbox{red}{\color{white}#1}}
\newcommand{\projectName}{Flood Simulation Browser\xspace}
% xspace only puts a space where we want one!
\addtolength{\footskip}{-200mm}
\addtolength{\headheight}{-05mm}
\addtolength{\headsep}{05mm}
\pagestyle{fancy}
\lhead{\projectName}
\rhead{\small F.S.B.}
%\cfoot{\footnotesize \textit{ \projectAbbreviation}\\[0.1cm] \small \thepage}
%\cfoot{}
%\rfoot{\thepage}
\setlength{\parindent}{0pt}
\setlength{\parskip}{10pt}
\begin{document}
\nocite{designing-touch, jQuery-Mobile, Siege}
\include{title}
%\thispagestyle{empty}
\newpage
\begin{abstract}
\end{abstract}
\input{fsb}
\newpage
\bibliographystyle{plain}
\bibliography{references}
\end{document}
\ No newline at end of file
docs/proposal/references.bib 0 → 100644
View file @ 398ca70b
@misc{Titanium-Appcelerator,
title = "Appcelerator, \url{http://www.appcelerator.com/}",
url = "\url{http://www.appcelerator.com/}",
}
@article{memoryleak,
title = "Why you should stay away from appcelerator titanium \\
\url{http://usingimho.wordpress.com/2011/0614/} \\
\url{why-you-should-stay-away-from-appcelerators-titanium/} ",
url = "\url{http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/}",
author = "A. Dallera" ,
}
@misc{CSS3,
title = "CSS3 Support, \url{http://www.caniuse.com/}",
url = "\url{http://www.caniuse.com/}",
}
@misc{designing-touch,
title = "designing-touch",
author = "Clark, J.",
year = "2012",
url = "\url{http://www.netmagazine.com/features/designing-touch}",
note = "Retrieved March 31, 2012"
}
@misc{jQuery-Mobile,
title = "jQuery Mobile, \url{http://jquerymobile.com/}",
url = "\url{http://jquerymobile.com/}",
}
@misc{PhoneGap,
title = "PhoneGap, \url{http://www.phonegap.com/}",
url = "\url{http://www.phonegap.com/}",
}
@misc{sencha,
title = "CSS3 Support, \url{http://www.sencha.com/products/touch}",
url = "\url{http://www.sencha.com/products/touch}",
}
@misc{Siege,
title = "Siege, \url{http://www.joedog.org/siege-home/}",
url = "\url{http://www.joedog.org/siege-home/}",
}
%http://www.sencha.com/products/touch
%http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/
%http://caniuse.com/
%http://www.joedog.org/siege-home/
%http://www.netmagazine.com/features/designing-touch John Clark 2012 on February 01, 2012
%http://www.appcelerator.com/
%http://jquerymobile.com/
%http://www.phonegap.com/
%\end{document}
docs/proposal/title.tex 0 → 100644
View file @ 398ca70b
\newcommand{\HRule}{\rule{\linewidth}{0.5mm}}
\begin{titlepage}
\begin{center}
\includegraphics[width=1\textwidth]{uva}\\[0.5cm]
\HRule \\[0.2cm]
{ \huge \LARGE \textbf{\projectName}\\[0.1cm]
\vspace{0.2cm}}
\HRule \\[0.4cm]
\Large \today
\vfill
\begin{tabular}{ll}
\textbf{Supervisor:} & \textbf{Executive:} \\
Robert Belleman - U.v.A & Richard Torenvliet \\
& stdnmr: 6138861 \\
& email: Richard.Torenvliet@student.uva.nl
\end{tabular}
\end{center}
\end{titlepage}
\ No newline at end of file
www/app/Api.js
View file @ 398ca70b
// GET /drfsm/<test_id>/results/izid/<izid>.csv
// for example
// GET /drfsm/5/results/izid/1234.csv
Ext.define('app.Api', {
mixins: ['Ext.mixin.Observable'],
singleton: true,
......@@ -13,7 +6,7 @@ Ext.define('app.Api', {
var me = this;
var requestName = Ext.Ajax.request({
method: 'GET',
url: 'http://sangkil.science.uva.nl:8003/area/1/izid.json?latlng=' + lat + ',' + lng,
url: 'http://sangkil.science.uva.nl:8003/area/'+area_id+'/izid.json?latlng=' + lat + ',' + lng,
success: function(response, opts){
var result = Ext.decode(response.responseText);
......@@ -21,26 +14,22 @@ Ext.define('app.Api', {
},
failure: function(){
console.log('failed to get izid');
console.log('getIzid: failed to get izid');
}
});
},
getCsvFile: function(test_id, izid) {
console.log(izid);
console.log()
console.log('/drfsm/'+test_id+'/results/izid/'+izid+'.csv');
var me = this;
var requestName = Ext.Ajax.request({
method: 'GET',
url: 'http://sangkil.science.uva.nl:8003/drfsm/'+test_id+'/results/izid/'+izid+'.csv',
success: function(response, opts){
console.log(opts)
me.fireEvent('gotCsv', response.responseText)
},
failure: function(){
console.log('failed to get csv file');
console.log('getCsvFile: failed to get csv file');
}
});
}
......
www/app/controller/ChartController.js
View file @ 398ca70b
......@@ -11,11 +11,13 @@ Ext.define('app.controller.ChartController', {
autoCreate: true,
},
chartData : {
ChartData : {
selector: 'flood-chart-id',
autoCreate: true,
},
ExpandButton: '#expand-button',
mapView: 'SimulationMap',
},
......@@ -26,11 +28,16 @@ Ext.define('app.controller.ChartController', {
'#closeChart': {
tap: 'closeFloodChart'
}
},
'#expand-button': {
tap: 'expandChart'
},
},
},
init: function(){
self.marker = null;
me = this;
app.Api.on({
gotIzid: function(izid){
......@@ -47,7 +54,19 @@ Ext.define('app.controller.ChartController', {
me = this;
this.getMapView().on({
gotClick: function(event){
app.Api.getIzid(event.latLng.lat(), event.latLng.lng())
if (self.marker != null) {
self.marker.setMap(null);
self.marker = null;
}
lat = event.latLng.lat();
lng = event.latLng.lng();
options = {
icon: 'resources/images/crosshair.png',
draggable: true,
raiseOnDrag: true,
};
self.marker = me.getMapView().createMarker([lat, lng], options);
app.Api.getIzid(lat, lng, me.getMapView().areaId)
}
});
},
......@@ -63,31 +82,31 @@ Ext.define('app.controller.ChartController', {
for (i = 1; i < array.length; i++)
{
line_clmns = array[i].split(',');
console.log(parseInt(line_clmns[0]));
data.push({
time : time.push(parseInt(line_clmns[0]) + i * 100),
volume : volume.push(line_clmns[1])
time : parseInt(line_clmns[0]),
volume : parseInt(line_clmns[2]),
time1 : parseInt(line_clmns[0]),
volume1: parseInt(line_clmns[2])
});
}
console.log(data);
this.openChart();
store.setData(data);
this.openChart();
},
getFile: function(result){
app.Api.getCsvFile(result['izid']);
openChart: function(){
this.getFloodchart().showBy(this.getMapView(), 'bl-bl');
},
closeFloodChart: function(){
this.getFloodchart().hide();
},
getData: function(latLng){
app.Api.getIzid(latLng.lat(), latLng.lng())
},
expandChart: function(){
}
openChart: function(){
this.getFloodchart().showBy(this.getMapView());
},
});
\ No newline at end of file
www/app/controller/Main.js
View file @ 398ca70b
......@@ -373,8 +373,4 @@ Ext.define('app.controller.Main', {
this.SimulType = 'Flood'
this.getSimulationOptions().hide();
},
pushSimulationList: function(){
//this.getSidepanel().push(this.getLsmSimulation());
}
});
www/app/store/chartStore.js
View file @ 398ca70b
......@@ -2,13 +2,13 @@ Ext.define('app.store.chartStore', {
extend: 'Ext.data.JsonStore',
config : {
fields: ['name', 'data1', 'data2', 'data3', 'data4', 'data5'],
data: [
{'name':'metric one', 'data1':10, 'data2':12, 'data3':14, 'data4':8, 'data5':13},
{'name':'metric two', 'data1':7, 'data2':8, 'data3':16, 'data4':10, 'data5':3},
{'name':'metric three', 'data1':5, 'data2':2, 'data3':14, 'data4':12, 'data5':7},
{'name':'metric four', 'data1':2, 'data2':14, 'data3':6, 'data4':1, 'data5':23},
{'name':'metric five', 'data1':27, 'data2':38, 'data3':36, 'data4':13, 'data5':33}
]
fields: ['time', 'volume'],
// data: [
// {'name':'metric one', 'data1':10, 'data2':12, 'data3':14, 'data4':8, 'data5':13},
// {'name':'metric two', 'data1':7, 'data2':8, 'data3':16, 'data4':10, 'data5':3},
// {'name':'metric three', 'data1':5, 'data2':2, 'data3':14, 'data4':12, 'data5':7},
// {'name':'metric four', 'data1':2, 'data2':14, 'data3':6, 'data4':1, 'data5':23},
// {'name':'metric five', 'data1':27, 'data2':38, 'data3':36, 'data4':13, 'data5':33}
// ]
}
});
\ No newline at end of file
www/app/view/Chart.js
View file @ 398ca70b
// var drawComponent = new Ext.draw.Component({
// config: {
// width: 100,
// },
// items: [{
// type: 'circle',
// fill: '#79BB3F',
// radius: 20,
// }]
// });
// var store = new Ext.data.JsonStore({
// fields: ['name', 'data1', 'data2', 'data3', 'data4', 'data5'],
// data: [
// {'name':'metric one', 'data1':10, 'data2':12, 'data3':14, 'data4':8, 'data5':13},
// {'name':'metric two', 'data1':7, 'data2':8, 'data3':16, 'data4':10, 'data5':3},
// {'name':'metric three', 'data1':5, 'data2':2, 'data3':14, 'data4':12, 'data5':7},
// {'name':'metric four', 'data1':2, 'data2':14, 'data3':6, 'data4':1, 'data5':23},
// {'name':'metric five', 'data1':27, 'data2':38, 'data3':36, 'data4':13, 'data5':33}
// ]
// });
// var chart = new Ext.chart.Chart({
// //animate: true,
// store: store,
// width: 500,
// height: 200,
// axes: [
// {
// type: "Numeric",
// position: 'left',
// fields: ['data1', 'data2', 'data3', 'data4', 'data5'],
// title: 'Numeric',
// minimum: 0,
// },
// {
// type: 'Category',
// position: 'bottom',
// fields: ['name'],
// title: 'Category',
// label: {
// rotate: {
// degrees: 35
// }
// }
// }
// ],
// series: [{
// type: 'area',
// highlight: false,
// axis: 'left',
// xField: 'name',
// yField: ['data1', 'data2', 'data3', 'data4', 'data5'],
// style: {
// opacity: 0.93
// }
// }]
// });
Ext.define('app.view.Chart', {
extend: 'Ext.Panel',
id: 'flood-chart',
......@@ -67,45 +6,53 @@ Ext.define('app.view.Chart', {
config: {
width: 520,
height: 220,
draggable: true,
height: 420,
layout: 'fit',
draggable: false,
items: [{
xtype: 'chart',
theme: 'Base',
animate: true,
id: 'flood-chart-id',
store: 'chartStore',
width: 500,
height: 200,
width: 520,
height: 400,
axes: [
{
type: "Numeric",
position: 'left',
fields: ['data1', 'data2', 'data3', 'data4', 'data5'],
title: 'Numeric',
fields: ['volume'],
title: 'Volume',
minimum: 0,
adjustMinimumByMajorUnit: 0,
},
{
type: 'Category',
position: 'bottom',
fields: ['name'],
title: 'Category',
label: {
rotate: {
degrees: 35
}
}
fields: ['time'],
title: 'Time Step',
minimum: 0,
adjustMinimumByMajorUnit: 0,
}
],
series: [{
type: 'area',
type: 'line',
highlight: false,
smooth: true,
axis: 'left',
xField: 'name',
yField: ['data1', 'data2', 'data3', 'data4', 'data5'],
style: {
opacity: 0.93
}
}]
xField: ['time'],
yField: ['volume'],
}],
// interactions: [
// {
// type: 'panzoom',
// axes: ['bottom', 'left']
// },
// {
// type: 'reset'
// }]
},
{
xtype: 'button',
......@@ -117,25 +64,22 @@ Ext.define('app.view.Chart', {
height: 30,
cls: 'closebutton',
style: 'background: url(resources/images/closebutton50.png) no-repeat; background-size: 30px; border: none',
}]
}],
// {
// xtype: 'button',
// ui: 'toggle',
// top: 0,
// right: 0,
// text: 'drag'
// },
// {
// xtype: 'button',
// id: 'expand-button',
// bottom: 0,
// right: 0,
// iconCls: 'expand',
// iconMask: true,
// }]
}
});
// (function(){
// var drawComponent = new Ext.draw.Component({
// items: [{
// type: 'circle',
// fill: '#79BB3F',
// radius: 100,
// x: 100,
// y: 100
// }]
// });
// new Ext.Panel({
// fullscreen: true,
// items: [drawComponent]
// });
// })();
});
\ No newline at end of file
www/app/view/List.js
View file @ 398ca70b
......@@ -15,7 +15,7 @@ Ext.define("app.view.List",
navigationBar:
{
title: 'simulations',
ui: 'charcoal',
items : [{
id: 'simulationOptions',
xtype: 'button',
......
www/app/view/Map.js
View file @ 398ca70b
......@@ -48,23 +48,35 @@ Ext.define('app.view.Map', {
*/
alterMapOptions: function(options){
this.globalExtMap.setMapOptions(options);
},
/*
* createMarker:
* sets marker at pos
},
/* sets marker at pos
* @params:
* pos = [latitude, longitude]
*
*/
createMarker: function(pos){
createMarker: function(pos, options){
var pos = new google.maps.LatLng(pos[0], pos[1]);
new google.maps.Marker({
if (options != null){
icon = options['icon'] || 'resources/images/Google_Maps_Marker.png';
draggable = options['draggable'] || false;
raiseOnDrag = options['raiseOnDrag'] || false;
}
else {
icon = 'resources/images/Google_Maps_Marker.png';
draggable = false;
raiseOnDrag = false;
}
marker = new google.maps.Marker({
position: pos,
icon: 'resources/images/Google_Maps_Marker.png',
icon: icon,
map: this.globalMap,
title: 'you'
title: 'you',
raiseOnDrag: true,
draggable: draggable,
});
return marker;
},
// 'http://sangkil.science.uva.nl:8003/drfsm/199419691/visualization/level/map/600.png'
......@@ -105,7 +117,7 @@ Ext.define('app.view.Map', {
/*remove clickevent and add to new image*/
if (this.listeners_ref != null)
google.maps.event.removeListener(listenerHandle);
google.maps.event.removeListener(this.listeners_ref);
this.listeners_ref = google.maps.event.addListener(this.overlayImages[0], 'click', function(event){
me.fireEvent('gotClick', event);
......@@ -124,8 +136,10 @@ Ext.define('app.view.Map', {
//this.overlayImages[this.imageIndex - 1].setMap(null);
this.overlayImages[this.imageIndex].setMap(this.globalMap);
if (this.listeners_ref != null)
google.maps.event.removeListener(listenerHandle);
if (this.listeners_ref != null){
google.maps.event.removeListener(this.listeners_ref);
}
this.listeners_ref = google.maps.event.addListener(this.overlayImages[this.imageIndex], 'click', function(event){
me.fireEvent('gotClick', event);
......
www/app/view/Simulation.js
View file @ 398ca70b
......@@ -9,13 +9,7 @@ Ext.define('app.view.Simulation', {
{
docked: 'top',
xtype: 'toolbar',
ui: 'charcoal',
title: 'Flood Simulation Browser',
items: [{
id: 'create-chart',
xtype: 'button',
text: 'create chart',
}]
},
{
xtype: 'SimulationMap',
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment