The Indiana Jones' life would be easier with MAGIS

Ricardo Martins
University of Minho
Braga
Portugal
ram@di.uminho.pt

Biography

Jorge Rocha
University of Minho
Braga
Portugal
jgr@di.uminho.pt

Biography

Pedro Henriques
University of Minho
Braga
Portugal
prh@di.uminho.pt

Biography


Abstract


When an archaeologist goes to a prospection or excavation, he must know something about the zone that he will prospect, discoveries made in that place and some other important information. After the expedition, all data is stored in a non-digital format, generally in paper, and easily this information will not be available for several months or years.

In this paper, we introduce a prototype tool that helps an archaeologist to access in the field information previously stored in a central database, to collect information in the field, using a mobile device, and store this information in a central server, that will manage archaeological information, like maps, discoveries geographic information, characteristics of objects found, etc.

MAGIS is prototype tool to study and improve the functionalities of archaeologic work, composed by 4 different modules: a SVG Viewer; a Deamon; a mobile Database Interface that runs in mobile devices; and a Manager that runs in a desktop, and manages the information in its database, working like a central server.


Table of Contents


Introduction
MAGIS Architecture
MAGIS-Viewer
     Features
     Why SVG ?
     Extension of SVG files
     Adaptations in the SVG Viewer
         Parsing adaptation
         Relation between SVG coordinates and GPS coordinates
         Overlapping maps
MAGIS-Deamon
     Data Synchronization
MAGIS-Mobile
     Implementation alternatives
     Synchronization
     Interface
Conclusion
Bibliography

Introduction

All archaeologists know that the routine is different than Indiana Jones movies. The activity of an archaeologist is related to the correct interpretation of several information sources. Before an archaeologist start the field work, he must study the place, from different information sources, to search for indications about the place that will be explored. When the information sources comes from the field work, raises a problem related to the digitalization and treatment of the large amount of information produced in the field, because this information is typically hand written by an expert, and some months later processed by another person who might not understand exactly the notes produced in the field.

From this process, we see major problems:

MAGIS Architecture

With the problems mentioned before in mind, we developed in University of Minho a prototype tool called MAGIS (Mobile Archaeological Geographic Information System), that has a central repository of all data collected in the various phases of the archaeological process (prospection, excavation, analysis and knowledge extraction, and distribution), and allows the archaeologist to use a PDA to support his activity on the field

Before start the field work, the archaeologist should upload to his PDA maps of the region he intends to explore and the view of the database related with this site; on the field he can use the PDA to access geo-referenced data and display maps, but he is also able to update the Information System introducing more data about the findings he is doing (referenced to the location where he discovered them); back in the central office he will synchronize the central database with his PDA database.

Using MAGIS, no delay will exist, transferring the information from the field to the office (it is just a synchronization process between two computer devices, taking a few minutes), and there is no duplication of effort, because the data is entered by the same person. A computer based interface can impose more restrictions to ensure data quality and standard procedures. So, MAGIS can offer support for thesauri navigation, data lookup, etc, enhancing the information captured.

MAGIS supports data collection can in place where the object is found. Due to hardware and technological limitations, the solution has been created using some different programs: a SVG Viewer(MAGIS-Viewer); a database interface (MAGIS-Mobile); and a middleware (MAGIS-Deamon) that connects the MAGIS-Viewer with the database.

It is possible to store and retrieve data in a server due to the MAGIS-Manager, which is an application that synchronizes the data in the mobile application and the server, using SQL Server 2000 Paragraph 58 and SQL Server 2000 CE Paragraph 58 gateway. The architecture of MAGIS is displayed below.

magis.png

MAGIS-Viewer

MAGIS-Viewer is a viewer that allows the graphic visualization of SVG Paragraph 58 maps in mobile platforms. It was created in Java Paragraph 58 , which provides a hardware independence, based on a SVG Viewer developed in University of Minho. Using MAGIS-Viewer, an archaeologist can see maps downloaded from the server, and their references previously stored. Picking up in any place within the map, it is possible to save information about an artefact in the position indicated, and get an information about a point showed in the map.

Features

The features of MAGIS-Viewer can be grouped in two groups:

  1. General applications:
  2. Archaeological applications:

Why SVG ?

The principal meaning of a map is display the information in a graphic format, enabling its interpretation by the user. If the map must be viewed in a mobile device, the hardware limitations must be considered in the choice of the technology applied.

Due to these limitations, maps must be small, simple, with no loss of quality in different sizes and, principally, must be portable.

With it in mind, we had chosen SVG, because the technology offers some features just like:

Extension of SVG files

To use SVG maps in real situations, it is necessary to provide complemental information, like the area of the globe that they cover. The first idea was to store this information at the metadata element, but the SVG's Document Type Definition (DTD) is very restrictive when using this element. It does not allow the existence of children-elements at metadata.

So, we decided to encapsulate the SVG file into another format created by us. Basically, our format file has two main elements: the "retanguloenvolvente" and the "svg". The "retanguloenvolvente" (involving rectangle) element has the GPS coordinates from upper-left and lower-right corners of the image. The "svg" element is the SVG map file. The schema of the file format is presented below.

schema.png

Adaptations in the SVG Viewer

Parsing adaptation

As mentioned before, the SVG does not provide support for geographic information. So, it was necessary to modify the parser to interpret the file format created by us. This new format contains the upper-left and lower-right corner latitude and longitude. Using this information, the dimension of the image is calculated and the GPS coordinates are converted to its lower scale value.

Relation between SVG coordinates and GPS coordinates

A SVG file can have attributes like width, height (which defines the dimension of the image) and viewBox. This last attribute has four fields. The first two defines the coordinates from the left-top corner and the last two defines width and height of the coordinate system that we want to use. Is important to keep this scale because the SVG image is defined to this coordinate system. So, it was created methods that relates pixels with values which scale was defined by the viewPort and with GPS values. It was created an inverse method that convert viewPort and GPS values in pixels. When the method generate a pixel value, the deformation is avoided due to a round method.

Overlapping maps

Every time that a map is loaded, the scale characteristics are passed to an object. The class of this object has the conversion method between scales. All instances of this class are stored in a hashtable where the key is the file name. After this, the map is parsed. For each SVG geometric picture, exists a respective class, where they will be instancied. The constructor of each element class will convert the initial values to the scale of the map that will be overlapped. The link between that the initial values and calculated values is the GPS coordenate. This mechanism is applied to all classes that represents SVG graphic elemens. So, all points will be converted to the map scale that will be overlapped. After the construction, the object is stored in an array that later is gone through to draw the picture. With this, we ensure that a map that overlaps another, will be the same scale of the first.

MAGIS-Deamon

MAGIS-Deamonis the simplest of the programs. Because SQL Server CE does not provide any driver for communication with Java, it was needed to develop a program that communicates at low level, that could access SQL Server CE tables. It was chosen develop it in C#, because it can have a direct access to SQL Server CE database native, and runs over the Microsoft .Net Compact Framework Paragraph 58 . It works listening a socket. When receives a stream in the socket (from MAGIS-Viewer), it processes the message, creating a SELECT or INSERT string, and executes the command. When the result is known, MAGIS-Deamon converts it into a string and sends it back, through the socket, to the MAGIS-Viewer.

Data Synchronization

The synchronization mode is relatively simple. According to the selection criterion chosen (the archaeological zone, for example), the information is copied to a temporary database. After this, the information is synchronized with the mobile database. When the archaeologist finishes to collect the data with the mobile device, the mobile database is synchronized with the temporary database. So the temporary database is synchronized with the central database.

MAGIS-Mobile

In the application developed to Pocket PC platform, the main characteristics are: synchronization of the information collected with the mobile device with the server; and generation of a simple interface to insert/update the mobile information. This application can manipulate information from many databases, because the user can change the database under work. This enables the user manipulate information from many archaeological places,from different databases.

Implementation alternatives

As it known, the mobile devices are storage limited as much as processing limited. Due to these limitations, many times appeared doubts about ways to solve problems, like the synchronization method (RDA - Remote Data Access - or Merge Replication), or load the assistant tables on start, fulfilling all the comboBoxes, and delaying the application start, but winning during its use. If do not load the assistant tables on start, the program starts faster, but its use will be more slower.

We chose the first option, because it looked better than the other. The synchronization method chose was Merge Replication, because one of the aspects of RDA is to copy the integral tables. This solution is accepted in a local update, but it will not be useful using GPRS.

Synchronization

The synchronization among the databases is made using the technology known as "Merge Replication". It consists in the copy among the databases of the modified information. It was done in the application like this: there is a menu "Data" that contains two synchronization options; one that allows synchronize only the information of archaeological tables, and the other that allow synchronize the information of all tables.

This option can be redundant, due to the fact of the synchronization of all tables, but if an archaeologist needs to synchronize the information on the field, by GPRS, the synchronization of all tables will be too slow.

Any update made locally must be saved locally, to synchronize to central database after.

Interface

The interface is easy to use, based in "Windows Forms". Due to the screen size limitation, it was used a system based in overlapped windows and comboBoxes to the assistant tables.

Conclusion

The main benefit that MAGIS brings to the archaeological community is a practical way to store and keep the information. All data collected can be accessed, stored, and manipulated according to the archaeologist needs.

Using SVG maps, the manipulation of the information in mobile devices is more efficient, allowing the user to retrieve the information rapidly, collect relevant data and storing in a standard format that can be easily manipulated later.

Due to the fact of SVG be an open protocol, and its files do not present loss of quality, its use is fundamental for mobile devices, where different hardware is available in the market, and the hardware limitations are imperative. The manipulation of the file is made through APIs, that enable an interaction between user and application.

As future work, it is possible to develop an interface using Web Services. It will allow to insert/select/update information from the mobile device to the central server, from anywhere the archaeologist is, and will allow an exchange of archeological data among archaeologists.

Because all of it, we say that the Indiana Jones life' would be easier with MAGIS.

Bibliography

[1]
Microsoft Corporation. .Net Compact Framework. Avaliable at http://msdn.microsoft.com/vstudio/device/compact.aspx.
[2]
Microsoft Corporation. Sql server 2000. Avaliable at http//www.microsoft.com/sql.
[3]
Microsoft Corporation. Sql server 2000 CE. Avaliable at http://www.microsoft.com/sql/CE/default.asp.
[4]
Sun Corporation. The source for Java technology. Avaliable at http://sun.java.com/.
[6]
W3C. Scalable Vector Graphics (SVG) 1.0 Specification. Avaliable at http://www.w3.org/TR/SVG/, 2001.

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.