Design Document Review Presentation

Design Document Review PresentationCharles Dunbar, Ben Kallal, Ankit Patel, Peter Purcell, Kody Reynolds

Our group is working on the Iowa Cycling Route Planning System, our client is Lisa XXXX from the Iowa natural heritage foundation. And our adviser is Dr. Daniels. My name is Ben Kallal......

1OverviewPurpose

Problem Statement There is currently no such application specifically designed for cyclists to create routes that make use of the bike trails in IA.

Solution

Presenter: BenPurpose The purpose of this project is to encourage increased use of bike trails in IA so as to raise their visibility to the average bicyclist. One of the Iowa Natural Heritage Foundation's major goals is to encourage the use of reclaimed railroads for use as bike trails.NEXTProblem Statement: There is currently no such application specifically designed for cyclists to create routes that make use of the bike trails in IA. There are lots of mapping programs out there like Google Maps but only a handful have any sort of support for trail data, and those are limited to a specific geographical area.NEXTSolution -- We propose an application where the user can plan out their own routes taking in account different options such as traffic count and difficulty of the route. 2Schedule

Presenter: Ben

Here is a basic outline of our plan for finishing up this project. So far we have finished the project plan and design documentation. We have also gotten all of the servers setup and running. Additionally we have started doing some prototyping for the user interface, the A* search algorithm and ArcGis. Next semester we will be working on the final implementation in the first few weeks of the semester and hope to be at a point where we can start testing and ironing out any issues we find issues from there. This leads us up to the end of the spring semester.3Functional RequirementsCreate a safe and efficient route between two locations in IowaWill support online access through any operating system that supports application supported browserWill support IE, FF, ChromeWill take a start and end location for routingWill have consistent routing algorithm

Presenter: Kody

1-Safe efficient route -- our applications first and main goal is safety. Any route the app returns should allow the users to navigate in a way they feel comfortable riding.2-online access 3-support IE, FF, Chrome -(appear with previous) -- We would like any os to be able to access our program for two reasons, 1 we want the program to be friendly to nearly all users, and second, we want users with smart phones/ipods/etc to be able to use it while on the trails. We would like to support the three most common browsers, IE, FF, and chrome.4- take start and end locations -- The user will be able to enter both start and end locations, which will be used by the other modules, mainly the ArcGIS module, to determine the most efficient route.5 - consistent -- The route that is returned must be consistent-- for example if the user inputs a start and end location on day one, then when they come back to the application on day two and insert the same information, our application must return the same results.

4Functional Requirements contWill route cyclists using a graphical interfaceWill display a route as an overlay of an Iowa mapWill allow the printing of a map with instructionsWill provide a code or URL that can be sent to another to exactly recreate the routeMapping data can be updated and maintainedPresenter: Kody

6- use graphical interface7 - overlay -(appear with previous) -- The returned route will be displayed to the user as a layer that will be shown on top of a Google maps image. This will allow them to see where there are going using an actual map.8 - printing -- this returned result will allows the user to print the map along with a list of turn by turn instructions , just as Google maps does.9 - code/URL - it will also display a URL or some type of code the user can use to access this same result again at a later date.10 - maintenance - The application must allow for INHF to update all of the Data Base information (where the roads, trails, and intersections are stored), and they must also be able to maintain current information to make sure that it still is accurate.5Non-Functional ReqUsability Must provide a positive service to the users to help accomplish their goals of finding the least-costly route Reliability Users must be allowed to access the web service almost always without any downtime and get back the correct least-cost path from origin to destination

Presenter: Kody

Usability-- obviously the first of our non-functional requirements is that the application must be usable. However when looking at usability more closely we want to make sure the users find that our application is very intuitive, easy to use, and that it gets them their desired results. Making the user feel comfortable using our app will be very important if we want them to continue to use it and even tell their friends about it.Reliability -- Another non func req we have is Reliability. This is very important because people will be using this app to navigate on trails they may not be familiar with, and if our app leads them astray, then there could be some serious issues. We also want to make sure they can get on at any time. Once again we wouldn't want them to get half way through their ride, and need to look at the map again, only to find that they could not access the website.

6Non-Functional Req, contSpeed The algorithm and user interaction with the application must be reasonably fast and responsive under normal use conditions Scalability Must be able to handle multiple requests at once up to an upper limit MAX_NUM_USERS that is defined Security The server module must be immune to attacks from external sources

Presenter: Kody

Speed -- This req could possibly be our biggest stumbling block. Speed is something that we have been taking into consideration since the beginning. We must provide functionality that does not make the user sit and wait 20 minutes for the algorithm to determine the quickest route. This would lose users real fast, and would be a pain to test. (leave this in?)Scalability -- We would like for our application to be able to handle several users at once. Our main concern in this area is when it comes time for RAGBRII. We believe that during this time there will be several people wanting to use our app, and we must be able to account for them.Security -- The final non func req, is that our application must have good security. It could be very dangerous if someone were to hack in to the database and change some information that would cause users to take the wrong routes, or busy interstates.

7System DesignOur proposed solution is made up of several different modules.

The modules communicate to one another using function calls.

The four modules include Client, Server, GIS Server, and Manual modulesPresenter: Kody

To simplify the project before us, we have broken down the application into 3 main functional modules, and a fourth module to cover the details. I will go over a very brief overview of these modules, and then some of the other members of the group will explain them each in more detail. First, the Client will be the module that is used to interact with the users. It will have to take in data, submit it to the other modules, and finally display the needed results. Second, the Server will be used to store all of our back end information that will interact with the secondary server, our next module, the ArcGIS module. This module will contain all the needed resources and data that will be necessary to do the mapping and get needed routes. The final module we will discuss is the manual module, this is simply the module that will contain all of our user documentation. How-To's, procedures, and maintenance guides.8Client ModuleThe website the end user seesCommunicates with the Google Maps via Google Maps JavaScript API .Communicates with ARC GIS Server via ARC GIS JavaScript API.Contains JavaScript functions to display routing information in visual and textual format

Presenter: Peter*CLICK*The Client module is the entire portion of the Application that the user sees and will drive the Application.*CLICK*We chose our client to be displayed as a html website that are styled with css and display mapping data through the Google Maps API. It also uses the Google Maps APIfor many vital functions such as geocoding.

The Client is modular and will drive routing by accessing the ARC Server via the ArcGIS Javascript API.*CLICK*After the Server has finished it will return a valid route and the Client will use the Google Maps API to display it.*CLICK*The client module also has many native javascript methods to display data as well as handle changing routing options and displaying map data.*CLICK*9User Interface SpecificationsThe User Interface will look similar in all browsersWill be extensible for the addition of future features.Designed to be useable by people with little computer experienceWill allow two users to get the same route with minimal effortCan support many concurrent users

Presenter: Peter

As the User Interface is so simple, we decided on a small set of specifications to define some of its constraints.*CLICK*User Interface needs to look similar in all browsers. This will be accomplished by using CSS and doing testing between the various types of browsers to detect differences. This is important to give users a consistent experience across all browsers as well as to ensure that as long as a customer has a support browser, they wont be adversely effected by it.*CLICK*The User Interface will be designed to be modular in its design, allowing changes to be made without breaking the interface between the Server and the Client. This is important because it allows our client the possibility of adding new features to the Application in the event that our app is used and there are requests for features.*CLICK*We want the application to be highly useable for users who arent very familiar with using internet apps. This is a primary reason for our usability testing that we will perform after the application is mostly complete.*CLICK*We need the UI to have a similar route with a certain consistency. This is mostly a server issue but it is also important for our use of Google Maps API to display routes with precision. We will cover this by performing General Route Testing and various unit tests.*CLICK*A final requirement for the UI was that many concurrent users can access the application. Since it is a website this should be a large issue but we will have JavaScript tests to do stress testing to ensure that there arent any slowdowns when the web server is taxed by many users.*CLICK*10UI Mockup

Presenter: Peter

We chose to use html and google maps to allow us to create a simple mockup using the API and allow us to easily prototype our application.

Our mockup contains all the elements needed for our Application.*CLICK*11Server ModuleHosts the client moduleWhere the mapping algorithm is executedThe mapping algorithm is the A* mapping algorithmReturns the path and biking directions to the client moduleHas a special custom object class for holding direction information and GIS data Presenter: BenThe server module is where the mapping algorithm is executed. NEXTThe algorithm that we chose for our mapping algorithm is the A* algorithm. This is a very popular algorithm for these sorts of applications and is very commonly implemented in video games for moving non-player characters. It is based on Dijasktra's algorithm but allows for a heuristic function which is how we can account for things like traffic count, and elevations when choosing which path to take. The algorithm is also nice because it is has a reasonable run-time, the number edges plus the number or vertices. There is some risk in that it has relatively high memory requirements but there are steps that can be taken to keep them within reason.NEXTIt also returns the path and directions to the client module as JSON object so that it can be parsedNEXTFinally it contains an internal object which holds both the GIS data and a string for constructing the text instructions12GIS ModuleHosts an instance of the ArcGIS Server

Contains GIS road data for all of Iowa, retrieved from the Iowa DOT

Communicates data to the server and client modulePresenter: Charles

We have been given copies of ArcGIS to work with for this project, which is a common application used for GIS work. *NEXT POINT* The Iowa DOT publicly provides all of their GIS data on their website, which we downloaded and use for our road data. *NEXT POINT* By creating the routing paths using the network analysis tool, we can host the map through ArcGIS server and allow for other modules to communicate with the data.

Pretty much exact same text, except notes for when i need to hit the next button so the points pop up as I talk about them.

13Example of ArcGIS routing

Presenter: CharlesIn a very simple prototype, I took Black Hawk county since its my home town, and created a routing path based on road length and chose three arbitrary points. By running the path solving tool, ArcGIS came up with this result, which appears to be a proper route using only road lengths to determine the path taken.

14Manual ModuleThe purpose of this module is to provide a simple and effective means of updating the mapping data on the GIS server.

This is necessary due to the complexity of the GIS server application.Presenter: Charles

The manual module is what we will create to give to our client when we are done with the project to show them how to update information. Since ArcGIS is free to non-profit groups, we assume they will be using it as well to maintain the information. The Iowa DOT updates its GIS data every June, so there will be a need for updates at least once a year. We will use screen shots and screen capturing tools to create videos if text and pictures alone are not enough to convey how to perform this task.

15Input/Output SpecificationsCommunication with GIS (to server and client module)

ESRI API ArcGIS developerAssociated Risk

AJAX callsInteractive web applications

Presenter: Ankit

A lot of the communication between the GIS and the server & client module will be handled using the API provided by ESRI and AJAX calls. *** ESRI is a company that produces GIS softwares such as ArcGIS. AJAX is simply a group of interrelated web development techniques used on the client-side to create interactive web applications.

There is a potential risk contained in getting GIS setup and working properly if ESRI updates their API and has a negative effect on the usability of our application.

16Software/Hardware SpecificationsApacheGoogle MapsArcGIS-Server server:Red Hat Enterprise 5.4Xenon X550 @ 2.67GHz CPU3042MB Memory10GB hard driveArcGIS Server 9.3.1ArcGIS Client server:Red Hat Enterprise 5.4Xenon X550 @ 2.67GHz CPU372MB memory8GB hard drive

Presenter: Ankit

Im briefly going to go over the software and hardware specifications of this project ***

Well be using a Apache web server for the purpose of hosting the website. ***The web application will be built on the Google Maps API ***The main ArcGIS-Server will run a current version of Red Hat Linux as the operating system with the listed specifications ***Well be using the latest version of ArcGIS server, version 9.3.1 ***And for the ArcGIS Client server, we will also be running a Red Hat Linux as the OS with some specific memory and hard drive requirements

17Users & Use Cases

Presenter: Ankit

The diagram here portrays the users and use cases for our system.

Users: Admin and User

The user is the person who will be accessing the application via the web.The admin will be responsible for maintaining and updating all mapping information, and also reassure that the routes being generated for users are valuable and useful

Lets briefly step through the use cases starting with the user

Generate a routeThe user wants to get a bike route to get from A to B, assuming that A & B are located within Iowas borders.

Process:Load the web applicationType in starting locationType in ending locationClick Get Route

The user will see the route overlaid on Google maps along with the text directions

Set PreferencesThe user may wish to change preferences with regards to the sort of route that they are looking for. The options they will be able to change are via a slider that will let the user select the safety versus difficulty level of the path. The other options that will be selectable are preferences for road types. For example, they user might prefer only a route with sidewalks or bike trails, and avoid any gravel roads.

Process:Load the web applicationClick the Preferences buttonChange preferences as desiredClick Save Options button

Print Route The user may want to print out text directions along with the visual maps of the generated route to take with them for reference.

Process:Load the webpageGenerate routeClick Print button

And the applications will nicely parse out the necessary information and format it in such a way that it is easy to read and comprehend

AdministratorA person employed or contracted by Iowa Natural Heritage Foundation to administrate the application.

Update and Maintain Map InformationThe administrator to update the GIS data on the ArcGIS server.

Process:Load ArcGIS Server Web InterfaceAccess ArcMaps functionalityUpload new GIS DataPublish ArcMaps

18Test PlanJavaScript Testing

Requirements Testing

General Route Testing

Usability Testing

Presenter: Charles

We will use javascript to stress test the system to test the amount of concurrent users that we can support.

For the requirements testing we will compare our application to the requirements that the client outlined at the beginning of the project.

For General Route testing we will create unit tests that will test the general viability and consistency of our routing algorithm.

For the usability testing we will task a group of test users19Evaluation PlanSurveyIn our survey the users will have the following tasks:Insert a departure and a destination.Select preferences.Analyze route given.

Presenter: Peter

Survey is a apart of the Usability Testing and will have users performing specific tasks and receive a Survey afterwards.

Questions we are particularly interested in are

Was the interface easy to use?What did you dislike?What did you like?Do you have any suggestions for our application

Because the front end of the application is going to be separate from the routing, it will mean this information will help us to be able to quickly prototype and add fixes noticed by the user as well as possible additions if time permits

We will pass portions of this survey over to the client so that if in the future they would like to puruse future enhancements, they have user data available for use.20Software Design - Client Module

Presenter: Peter

This is a simplified overview of the Client Module. After the website is done with its initial loading, it displays all the elements and waits for user input.

The two main control paths are for changing options to affect the way the route will be calculated. There is also a condition where a user inputs two valid addresses. If they are valid then the addresses are geocoded in to Latitude and longitude and then passed to the server.

After the server is done creating a route, it then send back mapping data to the UI. The application converts the data in to a form that can be displayed by the google Maps API. It also displays directions for the given route with the assistance of the API.

After the route is finished, the user has the option to change the options or get another route but either case will need the server to recreate a route.21Software Design - Backend

Presenter: Ben

This is our backend software design. Basically the process will flow like this:The server module will receive the GeoCoded form the client module and then look it up in the arcGIS module. Then the mapping algorithm will be executed.After that the route will be checked for validity. if it is valid then it will be it will be converted to KML, the language that is what Google Maps uses to display layers on top of the map image. If the route is not valid an error will be displayed to the end user.22RisksLosing a team member.

Limited web programming

Knowledge of GIS

Mapping algorithm

Google changing the API

Losing a team member. We will notify our advisor and professor in case such an incident does occur.NEXTLimited web programming. Some members of the team have experience, while some have minimal experience. Learning from other team members will minimize this risk.NEXTKnowledge of GIS. None of us have any experience with GIS so it will be challenging to work with the GIS data. We have resources from INHF and some other faculty members at ISU who can help us or refer to other resources that might.NEXTMapping algorithm. The mapping algorithm may be very complex and difficult to analyze. Choose a well known algorithm that can beNEXT Google changing the API. Hope for backwards capability, and be as modular as possible.23Questions?Presenter: Ben24