Last updated: May 15, 2001

A Mars Global Terrain Database

A paper on a design for a Mars Global Terrain Database was published in the Journal of Software Practice and Experience in May, 1999. Below is an abstract and summary from the paper - amounting to just under 10% of the paper.

ABSTRACT This paper discusses a modularized design for a Mars Global Terrain Database. The design provides for elevation data with respect to a triaxial ellipsoidal reference datum developed for Mars by USGS. Terrain data is recorded for 1-second of arc almost square grid elements over the surface of Mars. A 2000-Gigabyte column-gridded relation called Terrain contains the surface terrain data. Data for Terrain is expected in 1999-2000 from the Mars Global Surveyor satellite currently in initial polar orbit around Mars. Each tuple of Terrain contains data for a N-S column-grid of 900 1-second grid elements. There is thus a set of tuples per 1-degree rectangle, with the number of tuples in the set decreasing with the cosine of latitude. Surface resolution is 16.5 meters or better. The design constrains tuple sizes in Terrain to permit efficient blocking and manipulation of the records of the underlying storage file. Terrain contains a virtual attribute function for geodetic computations relating to the triaxial ellipsoidal reference datum.

The database also relates Mars feature-type relations to Terrain. Terrain's gridded structure is transparent to users writing SQL expressions to retrieve Terrain data on the basis of specific features. Many different distinct feature-type relations can be included. A least two of these participate in recursive relationships. The design also allows attachment of additional feature-type relations in a modular manner, correctly related to Terrain without affecting the contents of Terrain. The design is intended to enable efficient exploration of the planet at all levels of scale.

The database will contain feature data and terrain data for a regular angular coordinate (arc raster) grid over the entire surface of Mars. At the core of the database is a 2000-Gigabyte relation called Terrain that contains the terrain data. It has a surface resolution everywhere, including at the poles, of 16.5 meters or better.

Data is recorded with respect to approximately 1-second of arc almost square grid elements. Each tuple of Terrain contains the latitude/longitude coordinates of a 1-degree curved rectangle, plus data for a N-S running column of 900 of these grid elements, a quarter degree of latitude long, called a N-S column grid, within the 1-degree rectangle. Thus for each 1-degree curved rectangle there are many Terrain tuples each denoting a N-S column grid. In the N-S direction there are four 900-grid-element N-S column grids per degree of latitude and thus four tuples. The number of tuples in the E-W direction, per degree of longitude, and thus the number of N-S column grids, varies from 3600 per degree of longitude at the equator to 15 at the poles. Within any N-S column grid each of the 900 grid elements has a N-S side of exactly 1 second of arc, and the eastern and western sides of a N-S column grid are meridians and intersect the poles. Also, within any N-S column grid, the E-W side length of each grid element will normally vary from 1.0 down to 0.98 seconds of arc for latitudes less than 78, but from 1.0 down to 0 for the column grid running from latitude 89.75 to 90. This arrangement ensures an almost square grid element, at least to within 2% for latitudes less than 78. Since 1 second of arc is close to 16.5 meters, it also ensures the resolution of 16.5 meters or better over the entire planet. (A N-S column grid can easily be visualized as equivalent to a stretch of highway in a N-S direction just under 15km long (or 0.25 latitude degrees) and about 16.5 meters wide, with sides that are meridians, converging slightly in the polewards direction, but completely convergent in the case of a column grid that ends at a pole.)

The Terrain relation solves four practical problems associated with a relation for Mars global data. First it enables tuple size to lie well within disk track capacity with current technology, and will not lead to complications with blocking the records of the underlying Terrain file. Increasing resolution to 0.5 seconds (or about 8 meters) will not affect this compatibility. Second, the design accommodates the fact that as latitude increases the surface length of a degree of longitude decreases. It does this by using an almost fixed angular coordinate grid element, whose N-S sides are meridians and whose size stays almost constant over the globe, but is sufficiently flexible to handle the convergence effect at the poles. The third problem solved is the geodetic problem of how to relate surface length of 1 second of arc to latitude, longitude and elevation for a triaxial ellipsoid in a convenient manner; it is solved by placing the virtual attribute function trax() in Terrain.

The remainder of the database has to do with relating Mars feature-type relations to Terrain. The fact that Terrain is structured so that there is a set of tuples per 1-degree latitude/longitude rectangle, the number in the set falling with increasing latitude, is essentially transparent to users writing SQL expressions to retrieve Terrain data on the basis of specific features, even though there are many different types of features, each requiring a distinct relation. This is the fourth problem solved by the design. At least two of the feature-type relations needed, namely Crater and Valley, are involved in recursive relationships, recursive many-to-many in the case of Crater and recursive one-to-many in the case of Valley.

Since all features have some attributes in common, each feature-type relation is in a 1:1 ISA relationship with a relation Feature that contains attributes common to all feature types. It is Feature that is linked to Terrain via a simple relationship relation FT. FT is estimated to be of the order of 1Mbyte in size, since it is likely to have a number of tuples comparable to the number of 1-degree curved rectangles on a sphere. The number of tuples in Feature is equal to the number of distinct Feature instances named on Mars, e.g. Ares Valles, Pavonis Mons, etc., and is likely to grow with time. As a result of this design there are no Feature-type relationship attributes in Terrain, so that it is possible to add additional feature-type relations in a modular manner. Since feature-type relations, such as Crater, Valley, Mountain, and so on, are each in 1:1 ISA relationship with Feature, a feature-type tuple inherits all the properties of the Feature supertype, including relationship participation.

The Feature/FT relations can be viewed as a relationship "bus" from Terrain, to which it is possible to attach any additional feature-type relation, regardless of any additional complexity due to recursive relationship participation. The design presented assumes that an initial implementation will include relations for only the most common features on Mars, namely the recursive Crater and Vally feature-type relations, and the ordinary Mountain feature-type relation.

From a data retrieval viewpoint, the structure seems to result in relatively straightforward SQL expressions for data retrieval. Where an SQL expression is complex, the complexity will not be due to unnecessary complexity in the database, but only to the complexity of the request, for example, a retrieval request involving one feature type within another feature of a different type, such as valleys in mountains, or one feature type within another of the same type, such as craters on top of craters, the recursive case. In the design, measured storage space is deliberately expended in order to reduce retrieval complexity. The total database size will less than a percent greater than the size of the core relation Terrain, so that consuming storage space for non-Terrain relations to reduce complexity makes sense.

It should be understood at the outset that the design presented for a Mars terrain database must necessarily be different from database designs with GIS for Earth use. A GIS product is essentially a component of a decision support system, for answering factual and analytic queries about what is possible, e.g. where to site a pipeline or a bridge or a school. A Mars terrain database has no such possible use in the foreseeable future (except perhaps on rare occasions to look for a landing site for a future Mars probe). Its sole purpose is exploration of the planet on both a large and small scale. It is this goal that has determined the design presented here. Another difference is that databases for GIS for Earth use, such as those with such popular systems as ARC-INFO, are normally designed as thematic layers, which are integrated to satisfy queries, the underlying layer being the natural terrain, and each additional layer being something man-made. For example, if layer 0 is terrain, layer 1 could be street layout, layer 2 could be parks and layer 3 could be buildings, each layer using an underlying grid or raster approach for the data involved. With the Mars terrain database there is no data about man-made entities. There is only data for the untouched natural terrain, or a single layer, so that the thematic approach of GIS software products, with their capability of handling a plethora of man-made geographic objects, is largely irrelevant. Indeed the SEDRIS data model for environmental databases, sponsored largely by DOD, is specifically aimed at man-made environments and simulations (and related military operations). Popular GIS products do have some potential for use with a Mars terrian database, however. GIS producs are excellent for map generation, so that retrieved MGTDB Terrain data can be down loaded to a GIS product for generating maps.

Return to Computer Science Department Home Page

Return to James Bradley Home Page.

Footnote

Sand dunes on Mars will clearly be a larger problem for Mars database designers than first anticipated, given the recent images from MGS. For example, the floors of the valleys in the labyrinth region of Western Kasei valley seem to be all filled with sand dunes.