Lab II – Prototype Product Specification
Dynamic Mapping Solutions
Rodney Blythe
CS 411W, Spring 2010
Janet Brunelle
April 7, 2010
Lab II – Prototype Product Specification 2
Table of Contents
1
Introduction ............................................................................................................... 3
1.1
Purpose ............................................................................................................... 4
1.2
Scope .................................................................................................................. 6
1.3
Definitions, Acronyms, and Abbreviations ......................................................... 7
1.4
References .......................................................................................................... 8
1.5
Overview ............................................................................................................. 9
2
General Description ................................................................................................... 9
2.1
Prototype Architecture Description .................... Error! Bookmark not defined.
2.2
Prototype Functional Description........................ Error! Bookmark not defined.
2.3
External Interfaces ............................................... Error! Bookmark not defined.
2.3.1
Hardware Interfaces ................................. Error! Bookmark not defined.
2.3.2
Software Interfaces .................................. Error! Bookmark not defined.
2.3.3
User Interfaces.......................................... Error! Bookmark not defined.
List of Figures
Figure 1. DMS Prototype Major Functional Components Diagram ................................. 10
Figure 2. User Interface Site Map .................................................................................... 11
Figure 3. Administrative Interface Site Map .................................................................... 12
List of Tables
Table 1. Comparison of Final DMS Product with the DMS prototype ................................ 6
Lab II – Prototype Product Specification 3
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 distributor 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.
Lab II – Prototype Product Specification 4
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 cannot 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.
1.1 Purpose
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 ZeroFootprint 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.
Lab II – Prototype Product Specification 5
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 icecovered Paths.
[This space is intentionally left blank]
Lab II – Prototype Product Specification 6
1.2 Scope
The DMS prototype will be a scaled down version of the full-scale final DMS product
that is intended to prove the feasibility of the DMS project. The area mapped by the DMS
prototype will consist of the Kaufman Mall region of the Old Dominion University campus as
well as a parking garage that is close in proximity. This area is complex enough to test a great
number of scenarios present in many of the regions that could potentially use the final DMS
product.
Feature
Real World Product
Prototype
Search
All buildings by street address,
name, and keyword
Routing / Rerouting
Kiosk Implementation
Special Event Information
Shortest and safest Route first
Stationary user access stations
Customizable events
programmed by Administrator
Configurable by Administrator
Only buildings surrounding
Kauffman Mall of ODU by street
address, name, and keyword
Full functionality
Not in prototype
Single preprogrammed event
User Interface
Safe Routes
Admin Interface
Node Management
Path Creation
Structure Management
Overlay Management
Preconfigured and hardcoded
Add, delete, and edit Nodes
Connect Nodes to create Paths
Add, delete, and edit structure
information
Multiple custom Overlays
Full functionality
Full functionality
Edit structure information
Enterprise-class Oracle solution
DMS Route-Finding Algorithm
Basic MySQL implementation
Full Functionality
Pre-determined Overlays built
into the database
Server
Database
Algorithm
Table 1 – Comparison of Final DMS Product with the DMS Prototype
As can be seen in Table 1, instead of user-created Overlays, the DMS prototype will have
pre-programmed Overlays. The pre-programmed Overlays can be created to enact a variety of
scenarios that could occur with a full scale implementation of the DMS final product.
Lab II – Prototype Product Specification 7
Therefore, the DMS project team is confident that the pre-programmed Overlays will be
sufficient to prove the feasibility of the final DMS product. Kiosk hardware will not be
implemented or deployed in the prototype target area of Kaufman Mall.
The database will be a simplified version of the final DMS product database. However, it
will be complex enough to prove the feasibility of the full-scale final product implementation.
The core of the DMS product, the DMS Route-Finding Algorithm, will have access to the same
database tables in the DMS prototype as in the DMS final product.
1.3 Definitions, Acronyms, and Abbreviations
Administrator: Designated personel who maintain and update map with changes and events.
Admin Interface: Interface though which the Administrator maintains the DMS map.
DMS: Dynamic Mapping Solution.
DMS Route-Finding Algorithm: Algorithm designed by the DMS Development team which
utilized weighted nodes and paths to compute a route between two map points as defined by
latitude and longitude.
Google Web Toolkit (GWT): Series of java libraries which allow for the creation of complex web
based applications.
Node: A point on the map described by a latitude and longitude which is used to
define pathways, doors, and other points of interest.
Overlay: Administrator defined state applied to one or more nodes which will encourage or
discourage the use of paths between the nodes due to events, construction, or inclement
weather.
Path: A link between two nodes representing a physical walkway defined by the Administrator.
Lab II – Prototype Product Specification 8
Remote Procedure Call (RPC): A communication between the client and server components of
the DMS used to request a route or map information.
Route: The resulting interconnection of physical paths established by the DMS algorithms
between two points as designated by the User.
Safe Route: Route based on the Administrator defined Overlays to avoid potential hazards.
Static Map: Basic map provided by a contractor which is used as a foundation upon which the
DMS node network is built.
Tomcat Lite: Web application server built into GWT.
Weights: Values assigned to Nodes which discourage the DMS route-finding algorithm from
traversing connected Paths.
1.4 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.
Lab II – Prototype Product Specification 9
1.5 Overview
The following product specification documentation provides a detailed overview of the
DMS prototype. A general description in Section 2 provides information regarding the DMS
prototype architecture, functionality, and external interfaces. The specific requirements for the
DMS prototype, including functional requirements, performance requirements, assumptions
and constraints, and non-functional requirements, are located in Section 3.
2 General Description
The purpose of the DMS prototype is to prove that a ground-breaking dynamic mapping
system is feasible using the various tools and expertise at the disposal of the DMS prototype
development team. Due to time and budgetary constraints, the DMS prototype will be scaled
to include only the features and capabilities that are necessary to prove the feasibility of the
final DMS product. Despite the scope of the DMS prototype, however, the scaled DMS project
will serve as a valid and thorough measure of the potential of the final implementation of the
DMS product.
[This space is intentionally left blank]
Lab II – Prototype Product Specification 10
2.1 Prototype Architecture Description
MySQL will be utilized as the primary form of data storage. An Internet-connected web
server running Tomcat Lite and Apache will be used to host the MySQL database, web interface
portal, and the Google Web Toolkit (GWT) powered Java applet. As Figure 1 shows, the
Administrative Interface and the User Interface for the DMS prototype will use the GWT to
interpret data from a MySQL database as well as to compile the Java applet output in the form
of JavaScript that can be displayed through the web interface.
Figure 1 – DMS Prototype Major Functional Components Diagram
Calculations using the MySQL data will be determined by the DMS Route-Finding Algorithm and
the other components within the Route finding module. GWT will serve as the means to access
data from the MySQL data abstraction layer. 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 web interface design will
Lab II – Prototype Product Specification 11
be placed around the DMS prototype JavaScript output to simulate the use of the DMS product
in a realistic client web environment.
2.2 Prototype Functional Description
The DMS end user will navigate to the DMS User Interface web portal using any
supported Internet-capable device. The web portal will direct the Internet browser of the enduser to the default welcome page of the DMS prototype. From the default welcome page, the
end-user can navigate to the main User Interface page of the DMS prototype. This page will
display the interactive dynamic map that has been rendered in JavaScript and compiled by the
GWT Java back-end.
Figure 2 – User Interface Site Map
Lab II – Prototype Product Specification 12
The end-user will then have the option to specify start and end locations, search a
particular location’s contents, or display a Route calculated been two locations. All three
options will not redirect to a different page within the web portal. Instead, each option chosen
within the interactive dynamic mapping interface will request new data from the GWT back-end
and then render the updated data as JavaScript without reloading the page within the web
portal.
Figure 3 – Administrative Interface Site Map
Administrative users will navigate to a uniquely designed web portal for the
Administrative Interface of the DMS prototype that is curtailed to the maintenance needs of
DMS Administrators. Assuming that an Administrator is not already logged into the web portal,
that user will be redirected to a login page within the web portal. Once proper credentials are
verified by a server-side script, an Administrator will be redirected to the default page of the
Lab II – Prototype Product Specification 13
Administrative web portal that displays the Administrative Interface and all associated control
panels. Just as is the case with the User Interface, any options or interactions with the
Administrative Interface will not redirect an Administrator to a different page within the web
portal of the Administrative Interface.
Within the Administrative Interface, an Administrator can choose from a set of tabs that
will load different modules. The test mode tab will allow an Administrator to view an identical
representation of the User Interface as it is seen by end-users. The design mode tab will enable
an Administrator to add, edit, and delete Nodes and Paths within the dynamic interactive
mapping interface. If a building is chosen within design mode, a dialogue box with enhanced
options will provide Administrators with the option to add, edit, and delete building
information. The Overlays mode tab will give Administrators the option to apply and view preprogrammed Overlays.
2.3 External Interfaces
The DMS prototype will consist of two external interfaces including a software interface
and a set of two user interfaces.
2.3.1 Hardware Interfaces
The DMS prototype will require an ODU Computer Science department server to host
and run the application; however, it will not need a hardware interface.
[This space is intentionally left blank]
Lab II – Prototype Product Specification 14
2.3.2 Software Interfaces
A software interface, designed using Java and the GWT libraries will serve as the both
the back-end for the two graphical interfaces as well as a communications portal between the
DMS prototype and all MySQL databases used by the entire application.
2.3.3 User Interfaces
There will be two graphical interfaces, a User Interface and an Administrative Interface.
The User Interface will be the end-user version of the application that provides users with the
core features and capabilities of the DMS prototype. The Administrative Interface will provide
verified Administrators with preapproved credentials the ability to maintain and update the
data that is used by the User Interface.
[Section 3 Placeholder – This space is intentionally left blank]