Supporting Worldwide Database Development in
GE Smallworld

Copyright (c) 2002 Mark B. Field.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license can be found at http://www.gnu.org/licenses/fdl.html.

Abstract

GE Smallworld’s database technology gives application developers the ability to store large area databases, including worldwide. You may require the world coordinate system of the worldwide database to have angular coordinates of Latitude and Longitude. This is not as easy as it appears. This paper provides information about how the developer can set the world coordinate system to use a geodetic or geocentric coordinate system and discusses the limitations of using this type of coordinate system.

Summary

Customer Requirements

The customer wanted to utilize 20 million square kilometers of existing data that covers a large area of the world’s surface. The existing data, captured using the World Geodetic System 1984 (WGS84) Datum, is stored in a geodetic coordinate system, with units of 1/1000th of an arc second (approximately 2.4in or 6.2cm at the Equator with radius of 40,000km). To mitigate cost and data conversion, the customer wants to keep the database in the same units and Datum. They also wanted the capability of editing this data in one contiguous worldwide database.

 

The customer required the ability to manipulate data in project coordinate systems. An example of this requirement is the “expansion” of line features (like roads and rivers) attributed with a width into area surfaces, which represents the actual coverage of the features. The width unit would be a Cartesian unit like feet or meter. The following figure shows that a constant width in projection is not constant in WGS84.

Smallworld Core Capabilities

Smallworld provides storage of coordinates as “scaled” 32-bit, signed integers in X and Y where floats (to the number of decimals described) are scaled to and stored as integers [+/-2147483647] (Core Spatial Technology Data Modelling: Data modelling elements (6) 6.2.4.1 Geometry storage in worlds). For example, a coordinate system with 5 decimal places will have extents of +/-21474.83647 units. The Z is stored in a Datastore table separate from the 2D coordinate (Core Spatial Technology Application Development Overview: Geometry (7) 7.2.3.1 Coordinates) as a signed 32-bit float in float_bucket collections.
 

Smallworld provides the ability to define a coordinate system for each world. It allows you to project the world data into a different coordinate system for the application, display, and trail parameters.

 

Implementation

Coordinate System Definition

To support the customer’s 1/1000th arc second geodetic system, an “arc_millisecond” unit had to be defined as follows.

unit_manager.dimensionality(:length).new_unit(

:arc_millisecond, angle_value, 30.922080759)

 

The factor (30.922080759) was calculated using the following method.

coordinate_system.new_proj(:wgs84,:longlat,{},coordinate.new(0,0),

:degree).unit_size_in_mm/3600000

 

This factor defines the scale in millimeters. In this case it is the “normal” scale in millimeters for one arc millisecond at the equator. Note that this unit must be defined in the session prior to defining the coordinate system and prior to opening any database, which has a world’s coordinate system defined with this unit.

 

Once the unit is defined, the coordinate system can be defined. In order to use the coordinate system as the world’s default, the ds_coordinate_system class is used.

ds_coordinate_system.new_proj(

:wgs84,:longlat,{},coordinate.new(0,0),

          :arc_millisecond,

          :name,:wgs84_millisecond,

          :external_cs_name,"WGS84 1/1000 Arc Seconds",

          :coord_ndec,0,

          :root_name,:wgs84,

          :group,"world",

          :in_cs_menus?,_true )

World Coordinate System Application

To set the world coordinate system the following method has to be invoked.

!current_dsview!.world.set_coordinate_system_by_name(

:wgs84_millisecond)

 

However, this raised a “coordinate_system_unit_mismatch” condition. The method that was raising this condition was tracked down to “int!world.coordinate_system <<”. It verifies that the defined coordinate system’s unit_size_in_mm is equal to the unit factor with which the world was created. Once this test was removed, the world’s coordinate system was successfully changed.

 

The “coordinate_system_unit_mismatch” test verifies the new world coordinate system units match the units that were used during the creation of the database. However, I could not create the database with arc milliseconds units, so I removed the test when applying the new coordinate system to the default world.

 

At this point, the database is ready to be populated with data.

Possible Enhancements

Coordinate System “Go to”

After importing the countries of the world and a cloudless earth image, I started investigating setting the graphic system to different coordinate systems. I noticed that if you are not zoomed close enough to the valid area of the coordinate system, the system will warn you of invalid coordinates. This is a nuisance, especially if you are not familiar with the coordinate system.

 

I proposed to create and store Real World Objects (RWOs) with a simple area and the coordinate system that define the valid bounds, within the arc millisecond coordinate system, of each coordinate system. This provides two advantages.

 

The first is when the user selects the coordinate system for the graphics system, modifications to the View Configuration Menu can be made to the following.

*      Finds the RWO that corresponds to the selected.

Zoom to the RWO geometry.

Then change the Graphics System’s coordinate system.

 

The second benefit to the user is that automatic detections of coordinate systems can be done. Automated methods can scan for the RWO to determine what coordinate system the selected geometry is in and do projected calculations. This of course would require the user to setup the coordinate system RWOs so they would not overlap. However care must be given when the selected geometry spans two or more coordinate systems.

 

For this client, the Military Grid Reference System (MGRS) will probably be selected. The MGRS is a regularly sized coordinate system area of 6 degrees longitude by 8 degrees latitude in most areas, between South 80 degrees to North 84 degrees and is based on the Universal Transverse Mercator (UTM) coordinate system. This will provide a non-overlapping set of coordinate system RWOs that cover the majority of the world.

Coordinate System Field Editor (or Join)

To support the above coordinate system RWO, one of the fields must identify what coordinate system the RWO represents. For ease of use, this identity should be editable through a list of the visible coordinate systems. This list can be presented to the user with a field editor that shows the available visible coordinate systems. The user will select one and the internal name of coordinate system will be stored with the RWO.

 

Another approach could be to allow a RWO to join to a Coordinate System object stored in the database. This would require some changes from GE Network Solutions to allow the developer to define this join in the CASE Tool.

Automatic Geometry Split and Topological Connectivity

Geometries that extend past the boundaries of the WGS84 coordinate system, +/-180 longitude and +/-90 latitude could be automatically split and then hyper connected. An example of this is at the International Date Line. If a feature was digitized beyond –180 or +180 degree longitude, then the feature should be split at the 180-degree longitude line and continued on the other side of the database. If this feature was topologically connected, then hyper nodes should be created to allow topological queries across the International Date Line. This methodology should also be implemented at the poles.

Examples

The following examples show a tiled version of a cloudless earth image from NASA’s Earth Observatory and a 10-degree grid stored in WGS84 1/1000th arc seconds.