€¦ · web viewcomparison of dms final product and dms prototype14 . 1 introduction. maps...

Lab 1 – Dynamic Mapping Solutions Product Description

Rodney Blythe

CS411

Janet Brunelle

February 9, 2010

Lab 1 – Dynamic Mapping Solutions Product Description 2

Table of Contents

1 INTRODUCTION...................................................................................................................................3

2 PRODUCT DESCRIPTION......................................................................................................................5

2.1 Key Product Features and Capabilities...................................................................................5

2.2 Major Hardware and Software Components..........................................................................8

2.3 Target Market and Customer Base.........................................................................................9

3 PRODUCT PROTOTYPE DESCRIPTION................................................................................................10

3.1 Prototype Functional Goals and Objectives.........................................................................10

3.2 Prototype Hardware and Software Architecture..................................................................12

3.3 Prototype Features and Capabilities....................................................................................14

3.4 Prototype Development Challenges.....................................................................................15

GLOSSARY..................................................................................................................................................17

REFERENCES..............................................................................................................................................18

List of Figures

Figure 1. Final Product Major Functional Component Diagram..................................................................8

Figure 2. Path Creation.............................................................................................................................11

Figure 3. Location Search with Displayed Route.......................................................................................11

Figure 4. ReRoute Due to Overlay.............................................................................................................12

Figure 5. Prototype Major Functional Component Diagram.....................................................................12

List of Tables

Table 1. Comparison of DMS Final Product and DMS Prototype..............................................................14


1 INTRODUCTION

Maps currently exist in a variety of mediums ranging from static paper formats to digital

displays. All of the current mapping solutions are often updated infrequently and cannot adapt quickly

to ever changing data values. Many of the current mapping solutions, such as paper format maps and

imbedded car mapping displays, cannot be updated without a physical interaction between the map

distributer and the physical mapping device. Some mapping solutions provide periodic updates to the

software portion of the mapping device. Unfortunately, in many instances, such updates occur

infrequently enough to reflect up-to-date map data.

Static maps, such as printed paper maps, require many resources and time to be updated and

reprinted to reflect changing map data. In some instances, a mapping provider must contract a map

design firm in order to alter a static paper map. Due to the cost and time lost in this contracting process,

many static paper maps are not updated to include altered data values such as new buildings and Path

obstructions.

A case study was performed on the campus of Old Dominion University (ODU) in order to better

understand the issues that map providers and users have in a medium-scale mapping environment.

ODU provides three primary static paper maps to the campus. The primary campus map is heavily

inundated with advertisements that cover a majority of the printed map; therefore, the map is often

quite confusing and cumbersome to read and interpret. The Parking Services map is not printed with

the same amount of advertisements as the primary campus map; however, it is much more expensive to

print and distribute. Every year, 30,000 copies of the Parking Services map are printed at a cost of

23,000 dollars to the university.

At ODU, offices and service locations are often moving from one building to another. The

current static paper map solutions available to the university are rarely able to reflect such changes in


data values in a timely manner. Since there is such a high cost to update the paper maps, it is

impractical to update, reprint, and redistribute a new static paper map every time a single data value

changes somewhere on the university campus.

Transportation throughout the Old Dominion University campus is often altered due to

temporary changes in certain areas of the university campus. In the event that a Path is flooded, one of

the three current static paper map solutions can not inform a pedestrian to avoid the obstructed Path.

In the event that a simple change occurs, such as the renaming of a building, a static map must be

completely redrawn and reprinted in order to be accurate. On the Old Dominion University campus,

many buildings have been built and renamed since the three primary campus maps were last drawn and

printed.

The Dynamic Mapping Solutions (DMS) product provides a simple and affordable solution to the

issues caused by non-dynamic mapping technologies. The DMS mapping product will feature user

friendly control structures and intuitive feature navigation. A Zero-Footprint Model will be used in the

final DMS product version; therefore, Administrators and end-users will be able to access the DMS

product through an entirely Internet based JavaScript web document. The Zero-Footprint Model used

by the final DMS product version provides Administrators and end-users with the ability to access the

DMS product as fast as their supported mobile device can render the DMS product. Administrators will

have the option to update the DMS product nearly anywhere in the world using a supported mobile

device.

Updating non-dynamic mapping technologies is often costly, especially if the mapping

technology is based off of a static paper map. The DMS product requires only a very short time to

update any editable structure on a particular DMS product map. Once an alteration is submitted by an

authorized Administrator, the update is made instantly available to end-users viewing and interacting


with the DMS product. The DMS product provides Administrators with the unique option to Route end-

users through only areas that are thought to be safer for pedestrians. Rather than routing an end-user

using the shortest possible Route, the DMS product can Route an end user around potentially unsafe

areas such as unlit or slippery ice-covered Paths.

2 PRODUCT DESCRIPTION

The DMS product is designed to reduce the need for university supplied printing materials using

a dynamic mapping interface that can calculate the shortest, safest, and most reliable paths for the end-

user. Administrators have a vast degree of control over customizable paths, scenarios, and other

features using a great number of DMS product features and capabilities. The end result for the client is

a dynamic mapping system that is both easy to update by Administrators and invaluably informative to

end-users.

2.1 Key Product Feature and Capabilities

The DMS product is comprised of two main user interfaces, the administrative interface and the

end-user interface. The end-user interface provides users with a dynamically updated walking route

map that can be interacted with using a variety of enhanced features and capabilities. The

administrative interface includes the core of the end-user interface; however, it also grants

Administrators the ability to use special features and capabilities designed to update and maintain the

map used by the end-user.

The administrative mapping interface of the DMS product will be editable using a user-friendly

point and click system. New Nodes can be added by simply clicking on the map where a new Path Node

is desired. Each Node along a Path can be selected in order to delete or edit that Node. To create a


Path between two Path Nodes, the Administrator only needs to create a Node and then select which

Path Nodes to connect to the new Node.

The Overlays library, within the administrative interface, contains a variety of dynamic custom

Path weighting templates that can be applied to the DMS product. For instance, if a certain area is

known to flood under certain conditions, an Administrator may choose to create a template that alters

the weight of certain Path Nodes in areas that are known to flood. This “flood hazard” Path weighting

template can then be applied at a later date in order to reroute the end-user away from flooded Path

Nodes.

The end-user interface provides users with the ability to search for a particular building or

destination by entering either the street address of a destination, the name of a destination, or

particular destination content (such as an office or service). Once a destination has been located, all of

the contents of a chosen destination can be viewed by the end-user. For instance, if an end-user

searched for the “Health Clinic”, the search could return the building name and office number of the

main health clinic for that area. The end-user could then click on one of the search results to be shown

on the location of that destination on the interactive map.

Specialized areas that are determined by an Administrator to be a parking garage or parking lot

are uniquely designated on the DMS product map. These specialized map objects can be used as

destinations or starting locations for pedestrian routing calculations in order to assist motorists.

Similarly to other map objects, these specialized parking areas can be found using the search

functionality of the end-user interface.

In order to interact with end-users that do not have supported Internet-capable devices, the

DMS product can be customized to interact with an end-user using a stationary map kiosk. These map

kiosks contain a full version of the end-user DMS product and can assist end-users that do not have the


option of viewing the DMS product on a mobile device. Even users with supported Internet-capable

devices may choose to utilize such map kiosks in order to view the DMS product on a potentially larger

and higher quality device.

After a starting location and a destination have been chosen by the end-user, the DMS product

will determine a Route for the end-user. By default, the shortest possible Route will be calculated and

displayed for the end-user. However, the end-user can choose from a number of alternate routing

options, such as the Safest Route.

[This space is intentionally left blank]


2.2 Major Hardware and Software Components

The DMS product is a Zero-

Footprint software application that uses Java to compile and output JavaScript to a web interface hosted

on a customer’s server. As can be seen in Figure 1, both the administrative interface and the end-user

interface use a supported Internet capable device to access a customer’s server that is hosting the major

components of the DMS product software package.

The administrative interface can be accessed from any supported Internet-capable device;

however, certain mobile devices may experience slower performance when viewing the administrative

interface depending on the individual specifications of each mobile device. Only authorized

Administrators with the proper credentials will be capable of gaining access to the administrative

interface. The administrative interface will be given full access to the database tables used by the DMS

product.

The end-user can view and interact with the public version of the DMS product using any

supported Internet-capable device. The public version of the DMS product does not allow end-users

Figure 1. Final Product Major Functional Component Diagram


access to any administrative tools available in the administrative interface. Therefore, the end-user

version of the DMS product will only have limited interactions with the database.

A web interface hosted on the customer’s web server will be used as a portal to display the

JavaScript output by the DMS product. A Java applet will be responsible for compiling the JavaScript

code that is output to the web interface portal. This Java applet will be based around three modules. A

database module will be reponsible for interacting with the MySQL database and returning data to

either the Path finding module or the client interaction module. The Path finding module will serve the

specialized purpose of computing Routes using a Path finding algorithm.

2.3 Target Market and Customer Base

The target market for the DMS product are primarily complex areas such as universities and

dense urban areas. Since the size of a particular area is not as important as the complexity, potential

clients of a smaller scale will also be targeted. Such potentially smaller clients include zoos, golf courses,

malls, and other pedestrian environments similar in size and complexity.

The more an area changes, the less likely it is to have an up-to-date map due to the high costs of

redrawing and reprinting maps. Therefore, the DMS product will be targeted at areas that are

constantly changing. Areas that change more often will receive a higher return on an investment with

the DMS product since every dynamic update using the DMS product has the potential to save a client

many thousands of dollars in map redrawing and reprinting costs.

The DMS product’s primary purpose is to aid in the dynamic routing of large amounts of

pedestrian traffic. Therefore, one of the targets of DMS marketing will be areas with a high percentage

of pedestrian traffic. More specifically, areas with large numbers of visitors will be more likely to require

the DMS product since new visitors have a potential to be unfamiliar with an area.


3 PRODUCT PROTOTYPE DESCRIPTION

The DMS product prototype will be designed with a mixture of both fully implemented and

scaled-down features and capabilities from the specifications for the final DMS product. The point-and-

click interface, as well as many other core features will be implemented in the product prototype.

However, more advanced functionality, such as Overlay templates, will be scaled down in order to meet

prototype deadlines. Despite the differences between the prototype and the final product, the

prototype will serve as a valuable test of the main functionality of the final DMS product.

3.1 Prototype Functional Goals and Objectives

The Google Web Toolkit (GWT) will be used as a portion of the engine that drives the client user

interface. A specialized algorithm will be used in conjunction with a system of weighted Path Nodes in

order to supply the client user engine with the most efficient Route to display. Due to the potentially

large scale of the calculations required by the client user engine and the Path finding algorithm, the

GWT library will provide a basis for increasing run-time efficiency.



An administrative user can choose from a variety of tool sets using the tabs at the top of the

administrative interface. As can be seen in Figure 2, the Map Design tool set allows an administrative

user to design Path Overlays and obstruction areas. Each tool is represented on the Map Design canvas

as a different color pin or shaded area.

As can be seen in Figure 3, the Test view

tool set can be used to view how the DMS product appears to end users. The DMS end-user version of

the product will appear identical to the Test View; however, all of the toolsets and the blue background

will be replaced by the customer’s web portal.

Figure 2. Path Creation

Figure 3. Location Search with Displayed Route


After an end-user has chosen a specific destination and starting location using the search area to the left

of the map in Figure 3, a Route is displayed with a blue line. If an obstruction Overlay has been set by an

Administrator, the Route displayed to the end-user will avoid the obstruction as can be seen in Figure 4.

3.2 Prototype Hardware and Software Architecture

As Figure 5 suggests, the administrative interface and the end-user interface for the DMS

prototype will use the GWT to interpret data from the MySQL database as well as to compile the Java

applet output in the form of JavaScript that can be displayed through the web interface. More complex

calculations will be determined using the back-end routing algorithm. MySQL will be utilized as the

Figure 4. ReRoute Due to Overlay

Figure 5. Prototype Major Functional Component Diagram


primary form of data storage. GWT will serve as the means to access data from the MySQL data

abstraction layer.

An Internet connected web server running Tomcat Lite and Apache will be used to host the

MySQL database, web interface portal, and the GWT powered Java applet. A web interface, hosted on

an ODU Computer Science department server Apache web server, will be used as a portal for displaying

the JavaScript that is compiled by the GWT powered Java applet. A simple user interface design will be

placed around the DMS prototype JavaScript output to simulate the use of the DMS product in a realistic

client web environment



3.3 Prototype Features and Capabilities

The DMS prototype will contain many of the same features of the final DMS product; however,

many of these features must be scaled in order to maintain the scope and the timeline for the DMS

prototype’s development. A complete list summarizing the specific features that can be found in the

prototype can be viewed in Table 1.

Feature Prototype Final ProductUser Interface - Search by: -- Address Building locations by address Building locations by address -- Building Building locations by name Building locations by name -- Contents Building locations by content Building locations by contents - Routing / Rerouting Shortest and Safest Route first Shortest and Safest Route first

- Parking Info Not in prototype Special areas designated as parking lots/garages

- Special event info Single preprogrammed event Customizable events programmed by Administrator

- Kiosk implementation Not in prototype Stationary user access stations - Safe Routes Preconfigured and hardcoded Configurable by AdministratorAdmin Interface - Point and click environment Semi-functional, minor testing Fully functional and tested

-- Add Nodes Click to add Click to add -- Delete Node Click to select, choose delete Click to select, choose delete -- Edit Nodes Click to select, choose edit Click to select, choose edit -- Connect Paths Connect Nodes to create Path Connect Nodes to create Path -- Overlays Click to add Nodes to Overlay Custom shapes and state modifiersDatabase Simple MySQL implementation Enterprise-class Oracle solution

AlgorithmModified A* Algorithm for Path finding Modified A* Algorithm for Path finding

Implementation Scale Kauffman Mall of ODU Entire campus or customer propertyTable 1. Comparison of DMS Final Product and DMS Prototype

The DMS prototype will enable the end-user to search a given area for a specific destination or

group of destinations. The end-user will be required to input a search query value and then choose from

a set of potential destinations with a similar name value. By selecting one of the returned search result

destinations, the end-user can view the specific location of a desired destination on the dynamic map

provided by the DMS prototype.


When a destination and a point of origin have both been selected, the DMS prototype can Route

the end-user from the point of origin to the destination using the shortest possible Route as the default.

After selecting a desired location, either by searching or manually selecting an object on the DMS

prototype map, an end-user will be given the option to view the contents of a specific building or

location. A pop-up window containing the contents of the building will be displayed directly next to the

chosen destination.

The Administrative Interface will be an editable elaboration on the End-User Interface. A series

of tabs will provide an Administrator with a set of advanced options that can be used to dynamically

alter either specific map objects or a group of map objects. The map design canvas will allow

Administrators to directly manipulate the Paths and objects on the end-user map. Path Nodes can be

added, edited, and deleted using a mouse click event.

Information for specific locations and destinations can be updated by the Administrator.

Specific offices or services within a location or destination can be added, modified, or deleted from

within destination viewing and editing area. The Overlays library will contain only Overlay that is

predefined in the development of the prototype. This Overlay will serve as a functional test of the

ability of the DMS prototype to reroute the end-user based upon the redefined weight of a group of

Path Nodes.

3.4 Prototype Development Challenges

Controlling access and managing the database content could prove difficult as the number of

data rows increase. Querying such large amounts of data from a single table has the potential to cause

performance issues related to the rendering speed of the end-user DMS prototype. These potential

database issues can likely be resolved with a well-formulated algorithm and minimalist data queries.


Since the DMS software development team is still in the process of learning how to utilize the

GWT libraries efficiently, there is a potential for difficult errors to arise that will take a great deal of time

and resources to correct. Fortunately, the DMS prototype is of a small enough scale that any GWT

issues will not likely cause dramatic setbacks.

The Path finding algorithm will likely be the most complex set of code within the DMS product;

therefore, there is a higher chance that the Path finding algorithm will take a longer amount of time

develop than other portions of the DMS prototype. By reverse engineering a proven Path finding

algorithm, the DMS team will save a great deal of time and resources that would have previously been

devoted to the planning and development of a new Path finding algorithm.


GLOSSARY

Overlay: Administrator defined state situationally applied to one or more Nodes which encourages or discourages use of associated Paths triggered by a special event.

Node: A point on the map described by a latitude and longitude which is used to define Pathways, doors, and other points of interest.

Path: A link between Nodes representing a physical walkway.

Route: The resulting interconnection of physical Paths established by the DMS algorithms.

Google Web Toolkit (GWT): Series of java libraries which allow for the creation of complex web based applications.

Tomcat Lite: Web application server built into GWT.

DMS: Dynamic Mapping Solution.

Administrator: Designated personnel who maintain and updates map with changes and events.

Safe Route: Route based on the Administrator defined Overlays to avoid potential hazards.

Zero Footprint Model: Software that does not require client software to be installed on an end-user Internet-capable device.


REFERENCES

Burke, Victoria E. Personal Interview. 21 Oct. 2009.

“Campus Map Options” Survey. 19 Oct. 2009.

Conlin, JC, et al. (2009, December). Digital Mapping Solution . Retrieved from http://cs.odu.edu/~411green/assignments/finalPresentation.pptx

Conlin, JC, et al. (2009, December 16). Digital Mapping Solution . Retrieved from http://cs.odu.edu/~411green/assignments/DMS_SBIR_Documentation.docx

Dynamic Mapping Solutions . (2009, December). Retrieved from http://cs.odu.edu/~411green/index.php

Long, James W. Personal interview. 23 Oct. 2009.

http://cs.odu.edu/~411green/index.php

€¦ · web viewcomparison of dms final product and dms prototype14 . 1 introduction. maps...

Documents