Figure 1: Client / server architecture of LUBIS
Jacqueline Gehrig, Werner Landolt
The paper presents experiences made when developing a prototype of an information system for a complex multi user environment at the Swiss Federal Research Institute WSL. The application combining ArcGIS with an Oracle database will be used to plan environmental reconnaissance flights and manage the aerial photos taken. Based on examples from the application, topics such as relationship classes, versioning of geodatabases and transactions between the ArcMap interface and the geodatabase are discussed. Simple examples are presented to show the strategy used to develop this multi user environment.
To provide a basis for survey and research, all of the aerial photos taken
by the Swiss Federal Office of Topography are managed in a Geographic Information
System (GIS). The INFO database currently integrated in this GIS is not up to
the standards of todays normalized and transaction orientated databases, which
leads to redundance and instability. Furthermore, this system (Gautschi and
Haegeli, 1997) which has been operating since 1988 does not allow recording
and editing data at the same time.
The research and development project LUBIS (Luft Bild Informations System) is
a redevelopment of the above planning and management system. Its aim is to develop
a new multi user information system with a modern database structure and a user-friendly
interface. This paper describes experiences made during the development of the
prototype of this aerial photo information system.
LUBIS is a collection of different modules which handle the planning, storage, querying and lending of aerial photos. These modules are all organized in one application and can be accessed from the main menubar. Every program part is menu-driven. In the underlying database spatial and attribute data of the pictures are stored but not the images themselves. As these are still analog they are stored in fireproofed archive rooms.
LUBIS consists of eight independent modules:
Flight planning and archiving module
In this module the photo flights are planned and the resulting data archived.
The planned flight data is used as an annotation file for the aerial photo labelling
and is imported into the camera's guidance system on the plane. After the flight
the metadata is imported back into LUBIS where the spatial and attribute data
are checked and stored.
Air traffic control module
Air traffic control maps are automatically generated for different airplane
types and air control spaces. The user chooses or draws the desired flightlines
which are immediately plotted on the map together with their required flight
altitude.
Query module
A complex query module is used to access the large data (spatial and attribute
data). This includes a query which uses calculated footprints to determine the
exact terrain covered by an aerial photo.
Address administration module
A module to register and edit the addresses of customers, film manufacturers,
camera lens suppliers and other relevant connections.
Aerial photo library module
The library administration module handles the lending of single aerial photos
or photo series to customers. Administrative processes such as term prolongation,
image return and reminders automatically checking for term expiration are easily
controlled through user menus.
Interface module
Different interface programs handle the information flow to and from LUBIS:
Information from the planned flights are exported in ASCII file format into
the flight navigation and camera systems. After the flight, the log-files are
imported back into LUBIS. To enable international data exchange coordinates
of pictures taken outside of Switzerland are transformed into WGS84 [1]
format.
Database management tool
Archive revision can be done manually or automatically. The attribute key tables
in Oracle can be accessed and new data set entries are possible through simple
user interfaces.
Service program
A collection of utility programs including duplication of planned flights, handling
of planned but not realized lines, and automatic generation of the annual aerial
photo index.
Hardware
The prototype was developed on a common Pentium III 600 MHz PC with 392 MB
Ram and 10 GB harddisk connected to an Oracle database on a Sun Ultra with 256
MB RAM and 350 GB harddisk through a 100Mbit LAN.
Software
The following software packages were used:
| application: | Esri PC-ArcGIS 8.1 with the product ArcMap and the programming language Visual Basic for Applications (VBA) |
| database: | Oracle 8.1.7.0 and the Esri ArcCatalog |
| connection: | Esri ArcSDE 8.1 |
ArcGIS, ArcSDE and Oracle were chosen for the client / server architecture (see figure 1).
Figure 1: Client / server architecture of LUBIS
The geodatabase model was implemented as a data model where entities are represented as objects with properties, behaviors and relationships. Relationships between objects can be defined following the rules to maintain referential integrity between these objects. This means more consistent data and less complicated application development. As a consequence for LUBIS all flightlines and pictures are stored as independent objects in a database permanently related to the attribute data. Because multiple user access is a precondition in our project and because the database will be located on a server, the multi user data model was chosen. Using the versioning function provided in ArcSDE, several users can access the data simultaneously (see figure 2). This allows planning new lines and managing the archive at the same time.
Figure 2: Data handling model
However, the combination of planning and archiving functions causes an additional
problem. As the planned flight lines have to be editable while the archived
ones need to be write protected, different access rights would have to be associated
with different records. So far, the database applications do not support this.
To resolve this problem, two approaches were looked at.
In the first model, the data of both planned and realized flights are stored
in the same table. In this case the records are distinguished by an attribute
defining data status as planned or final. Access to the final data must be limited
to read only. However, full access to the planned data must be given. To realize
such access control, Oracle views were considered providing read only access
to the underlying data table.
The second approach was to design two tables: one with the planned data and
one with the final data. Thus providing an easy way to solve the access problem
because the entitlements are set on the tables. However, the data are stored
twice, which increases database size and the administration expenses.
The prototype was divided into the following components: the database, the application, the connection between database and application, and the versioning of the database. These four components were studied thoroughly.
Database
The database was created with ArcCatalog, first as a personal geodatabase in
MS Access format. Attribute tables were designed in MS Access and then imported
into the personal geodatabase. The existing ArcInfo coverages were imported
directly to the geodatabase and structured into feature datasets and feature
classes. The spatial tables were then linked by composite [2]
relationships to the attribute tables by setting primary and foreign keys. As
composite relationships do not allow many-to-many (m:m) relations new tables
were created when needed. Finally, the personal geodatabase, respectively the
feature data sets, were transformed in ArcCatalog to Oracle via ArcSDE: a multi
user geodatabase was generated.
Application
The programming environment within ArcMap uses the VBA language. Although this
is not a GIS language like AML (Arc Macro Language), it is enhanced by the object
environment of the Esri libraries. They provide use of GIS methods and properties.
First experiences show that although VBA does not provide all of the methods
of AML, solutions can be found. The COM-Add-In [3]
architecture makes it possible to find a solution even when the limits of VBA
are reached. If a problem cannot be solved with VBA it is simply programmed
in another COM programming language, e.g. Visual Basic (VB) and imported as
a dll [4] into the ArcMap environment.
There, it can be called from a VBA script. The following example demonstrates
an attempt to solve a problem with VB instead of VBA:
The application called for a script creating a new flightline after the user
interactively selects start and end points of a new flightline on the screen.
The resulting object should be a simple line consisting of two points only.
In addition, the respective shape should be created automatically.
First, the Esri Object Libraries were made available in the VB programming environment.
Then the code was written using different ArcObjects, e.g. PointCollection,
PolyLine, Fields, Feature. After compiling and registering the script as a dll,
it was added to the "Esri Edit task" component category through the
component category manager.
The dll "new_flightline" then was called from a VBA script by implementing the following code:
Dim pEditor As IEditor
Dim pID As New UID
pID = "EsriCore.Editor"
Set pEditor = Application.FindExtensionByCLSID(pID)
pEditor.StartEditing GetWorkspace
("test_range")
ChangeTask pEditor, "new_flightline"
Another advantage of the VBA programming environment are the GUI-builders [5] VBA uses as a central development tool and which produce a well structured program. However, with this approach the code has to be saved with the application. In a multi user application with ArcGIS not running on an application server but on the different computer clients this is very time-consuming and difficult to support and update.
Connection
The connection between the ArcMap application and the Oracle database is managed
by ArcSDE. It handles the geodatabase and organizes the multi user access.
Versioning
ArcSDE allows for a database to be versioned. This means that multiple users
can access and modify geographic data simultaneously and create multiple representations
of the database without data replication. If the same object is modified a conflict
resolution box guides the user through the process of determining the object's
correct representation.
Database
User access rights were assigned in ArcCatalog and the settings checked in Oracle.
To test the data consistency different entries with the same primary key were
implemented, and in the main table selected records were deleted.
In the test runs, the relational Oracle database managed the user access rights
correctly and ensured data consistency. Redundant entries were not accepted,
unlike in the previously used INFO database. The cascading editing of data was
reliable, too.
Application
The start bar and two queries from the old application were chosen for implementation
in the new prototype in order to test the behavior of menus, the transactions
between Oracle and ArcMap as well as the graphical display of spatial and attribute
data. The existing AML programs were translated into VBA and fitted to the object
environment of the Esri libraries.
The following two queries were realized:
The above mentioned menu-driven queries implemented in the prototype all worked fine (see figure 3).
Figure 3: Display of flightlines in the Swiss national park
as a query result
The start bar was implemented without problem. However, the AML function "threading" which allows holding open several menus at the same time, and which was needed for some queries could not be translated. In the new programming environment there is no method or menutype for this special kind of menu. However, the menus could be simulated by VBA forms.
Connection
Both the manual login and the automatic login to the Oracle server were tested.
The response time when displaying large spatial data (around 150'000 records)
and querying complex attribute and spatial data was monitored. Also, an Oracle
view from data in three tables was created, thus testing transfer of spatial
and attribute data from different sources. Both manual and automatic connections
between the database and the application worked without failure. However, there
were problems loading and displaying the Oracle views created in ArcSDE. One
view selected different attributes out of three tables, one spatial table and
two attribute tables, involving 8500 records. The time needed to display this
view was around 10 minutes. To display the respective attribute table the system
needed approximately the same time. During this display process countless log
files were created on the Oracle server, its performance reduced to nearly zero
thereby blocking other users processes. Esri is currently working on a solution
for this problem.
Versioning
Versioning was tested for both spatial and attribute data. With the intention
to cause a conflict a single dataset on the server was simultaneously accessed
from two computers. Conflicting changes to the object followed by an attempt
to save the data were made. Using Oracle 8.1.5 on the server, versioning did
not work at all. After an update to Oracle 8.1.7.0, one user could reconcile
and post his version. However, while the second user tried to reconcile his
version, ArcMap crashed without any error message. By closing down ArcMap before
reconciling the second version and opening a new ArcMap session, an error message
was produced after the reconciling process, showing that ArcMap tried to access
an unrelated, already versioned database schema which was located on the same
Oracle server. Access to this "foreign" database was correctly denied, the
versioning process blocked. Only after the server was cleared of all other versioned
databases the versioning of the LUBIS database worked without problems.
The client/server architecture and software packages chosen for the prototype
performed well in the tested situations. Valuable information was gained on
the possibilities and limits of the database structure and the developing tools.
The results showed that the multi user environment required for LUBIS could
be developed without cutting back on data integrity and user comfort. The new
VBA programming environment in ArcGIS is comfortable, the Esri libraries i.e.
the methods and properties used in this project worked fine.
The data flow from and to the geodatabase was handled properly by ArcSDE. Versioning
of database tables allowed simultaneous access by multiple users. Querying and
editing data stored in tables was possible. However, data access through Oracle
views was not yet satisfactory. The performance while displaying views was insufficient
and the process even rendered the server instable. Therefore, the data model
using two tables to protect the archived data was preferred to the use of Oracle
views (see chapter data model design).
These experiences with the prototype are used in the implementation of the new LUBIS application and database which is currently under way and will last until July 2003. After testing and validation, the application will be installed at the end of the year 2003.
[1] World Geodetic System of 1984
[2] in a composite relationship the lifetime of one object controls the lifetime of its related objects. See McDonalds (2001), chapter 6: defining relationship classes.
[3] COM = Component Object Models
[4] dll = dynamic link library
[5] GUI = graphical user interface
Gautschi, H. P., Haegeli, M. (1997): Das Luftbildinformationssystem der Eidg. Vermessungsdirektion und der Eidg. Forschungsanstalt für Wald, Schnee und Landschaft. Vermessung, Photogrammetrie, Kulturtechnik 2/97.
MacDonald, A. (2001): Building a Geodatabase. Redlands CA. Esri Press.
Jacqueline Gehrig
Swiss Federal Research Institute WSL
Section Landscape Inventories
Zuercherstrasse 111
CH-8903 Birmensdorf, Switzerland
e-mail: jacqueline.gehrig@wsl.ch
phone: +41-1-739-2571
fax: +41-1-739-2215
Werner Landolt
Swiss Federal Research Institute WSL
Section Forest and Environmental Protection
Zuercherstrasse 111
CH-8903 Birmensdorf, Switzerland
e-mail: werner.landolt@wsl.ch
phone: +41-1-739-2314
fax: +41-1-739-2215