1 2004 
  
AAMS 
data, 
] into 
fully, 
of the 
n files 
zation 
es are 
same 
realize 
2 still 
make 
ration 
s Is to 
rS and 
The 
\eris’s 
ctions. 
s Data 
emote 
other 
Server 
aining 
ervers 
| it, to 
'ement 
inated. 
server 
cation 
e type 
vers to 
1at are 
rracted 
: Aeris 
binary 
er plus 
ide the 
ication 
essage 
on it is 
pes as 
ses t0 
from 
orm or 
iternet. 
ipports 
ynsible 
n the 
ve the 
quests 
‚stands 
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004 
the common protocol and the module's data structure can 
connect to the Data Module and receive data. It can be 
configured without need to modify the source code, enabling 
rapid setup of new MAMS applications and projects. The Data 
Module is expected to work in a one-to-many environment. 
That is to say, in an environment where multiple users are 
expected to access the module simultaneously. The Java Servlet 
technology fits this requirement well, given its seamless 
handling of multi-user access. It also makes it possible for only 
one instance of the Data Module to handle all the clients, thus 
minimizing its memory footprint. 
The Data Module works in conjunction with the 
Communication Module. The Communication Module obtains 
from the received Aeris message, the raw number string and 
hands it to the Data Module. The Data Module then decodes the 
number string into meaningful information, based on the 
configuration set in the remote sensor and stores the 
information into relational databases. There is a separate 
Database component within the Data Module that is used to 
handle the database management aspects. This is necessary as 
the database is among the most variable aspect in a MAMS as 
any changes in assets, or collected asset information would 
have to be reflected in the database. Communication between 
the Module and the databases are done through a standard 
public interface and queries to help abstract the structure and 
format of the actual database. This use of encapsulation helps 
minimizes the effect that any changes to the asset data 
collection process would have to the whole Data Module. The 
Database component is where the number string decoding 
occurs and where the necessary queries and update functions 
used to interact with the actual databases are held. The database 
product currently used is Microsoft Access, but all transactions 
with databases involve the standard ODBC protocol, which will 
allow different database software packages to be used in place 
of Microsoft Access if necessary. 
When providing vector data, the Data Module first opens the 
ESRI Shape file to decode into an array of separate vector 
features. This array is then broken apart into a Multi-Layer 
Storage Scheme (MLSS), which is a key optimization for 
reducing the search time for a request. This storage scheme 
works by having several levels that cover the entire vector map 
area; each level contains geospatial features of varying size, 
With no feature being duplicated between the levels. 
Furthermore, each level partitions the map area into a certain 
cell size, with lower levels having smaller cell dimensions and a 
greater number of cells as compared to higher levels. 
The topmost level has only one cell that contains the entire 
map. As each vector feature is decoded from the ESRI Shape 
file, its boundary coordinates is then added into the smallest 
possible cell that they can fit into. By sorting the vector features 
into different cells, only a fraction of the entire vector data set 
needs to be searched for the majority of client requests and 
thereby greatly improve the responsiveness of the system. The 
MLSS is fully customizable; the number of levels, the number 
of cell partitions in the horizontal and vertical can be adjusted 
to best match the vector feature density characteristics of any 
particular dataset. As the Data Module is built upon a Servlet 
foundation, the vector data is stored into global memory, so that 
threads created to service requests from multiple users share the 
vector data and thereby reduce memory usage. The vector data 
is persistent in memory, even after client threads have been 
destroyed once requests have been serviced. This ensures that 
the time and processor consuming procedure of decoding the 
ESRI Shape file only occurs once during the Data Module's 
initialization phase. 
The Data Module also provides raster data, most commonly 
with MapPoint Web Service. MapPoint provides global spatial 
data and extensive street maps for North America, Europe and 
many cities in South America. This large amount of spatial 
information from one source is essential for providing services 
to companies with assets spread over entire regions or 
countries. 
Requests for data are received by the Data Module through the 
Servlet communication method. All forms of user request 
follow a standard protocol, which indicate the type of request 
and other associated information required by the server to 
perform the request. The server then performs the request and 
then packages the requested data into a single message and 
sends it back to the user. After receiving a request, the Servlet 
performs the operations necessary to accomplish the request 
and sends the results back to the requestor [Lee and Gao, 2002]. 
Configuration of the Data Module can be done through two 
methods. The primary method is through adding parameters 
into a standard XML based configuration file used for each 
Servlet. The second supported method is to have the XML file 
provide the location of a separate configuration file, which 
would be parsed by the Data Module. These configuration 
methods provide the Data Module with important parameters 
such as the location of the vector data, the ODBC name of 
associated databases and the coordinates of the desired map 
extent. In this way, different projects can be created using the 
same template Data Module and without the need to modify the 
source code or to write any additional code. 
3.2.3 Application Module 
The Application Module consists of a Server component and 
also the Web Client which helps users access data and tools. 
Whenever a user connects to the Application Module through a 
browser, the Web Client, which is the other component in this 
module, is downloaded and proceeds to run on the user’s 
computer. By centralizing the storage.and distribution of the 
Web Client, benefits can be realized through reduced support 
and administrative costs. Administrators need only to apply 
updates and bug fixes to the Application Module code base and 
users can be confident that they are using the latest version of 
the Web Client whenever they connect to the Module. 
The basis of the Web Client is the Java Applet, which allows 
for the creation of a software application that offers a graphical 
user interface that would easy for users to grasp. It also enables 
the application to run on multiple platforms without any need to 
modify the source code. The Web Client includes a Toolbar 
component, a Statusbar component and a Map component plus 
a Parent Shell and is based on a Model-View-Controller 
scheme. The Toolbar is the Controller in the Web Client as it is 
responsible for receiving inputs from users and controlling the 
application based on the inputs. The Parent Shell acts as the 
Model, containing the majority of the Web Clients logic. It 
also links all the other components together, passing controls 
and notifications to the View and for communicating with 
Platform server-side modules. The Statusbar component is used 
to display text information passed to it from either the Map or 
Toolbar components. The Map component is used to display 
the geospatial data via a graphical presentation. Both the 
c