Spatial Data Structure

The architecture of a SOLAP system is composed of a multidimensionally structured spatio-temporal database, a SOLAP server and a SOLAP client [1]. The spatio-temporal database stores the geometry associated with spatial dimension members and spatial measures. The SOLAP server handles the spatio-temporal multidimensional database and the numerical and spatial calculations necessary to compute the measure values associated with possible combinations of dimension members. Currently, no such server is available on the market; it must then be implemented using a custom combination of technologies.

Such system must provide capabilities to adequatly handle spatial data, such as the capabilities described in the following sections.

Information of this page is from Rivest, S. et al. [5] and Proulx, M.-J. & Bédard, Y. [6]

Support for a spatial datacube structure

The SOLAP Tool must include a spatial datacube structure to manage and configure the spatial elements. This structure must contain spatial dimensions organized in a hierarchy of spatial members. For example, the structure must support the abstraction layers composed by world, countries and provinces elements. This is different than managing map layers where spatial elements are organized by level and no hierarchical relationship exists between the levels.

Support for several spatial data sources

Within an organization, spatial data are usually available in various formats. In a data integration context like spatial datacubes, it should not be necessary to standardize or translate these data formats. A SOLAP tool should then be able to access the most common vector and raster formats of the GIS industry (ex. ESRI Shapefiles, Mapinfo Tab, SVG) in a native way.

Support for many spatial dimensions in a spatial datacube

In a SOLAP application, it can be necessary to map data on several spatial dimensions. The system must then support more than one spatial dimension per cube. For example, measures can be assigned to power lines (lines) and regional districts (polygons).

Support for all simple and complex spatial primitives (ISO standard)

Spatial elements can be grouped into three subclasses: base geometries (ex. points, lines and polygons), complex geometries (ex. line networks), and multiple geometries (ex. polygonal and linear networks). The geometry describes the shape of objects with coordinates and mathematical functions.

The International Organization for Standardization (ISO) produced the 19107-Spatial Schema standard that defines a set of spatial data types and operations for geometric and topologic spaces. The geomatics community uses these rules when developing geospatial applications.

Montreal is an example of aggregated polygons where all islands compose the complex geometry of the global element.


Support for historical spatial data

Building multidimensional systems requires gathering data from heterogeneous sources. Then, data is integrated in multidimensional structures organized around several analysis axes, or dimensions. These analysis structures are likely to vary over time and the existing multidimensional models do not (or only partially) take these evolutions into account. Hence, a dilemma appears for the designer of data warehouses: either keeping trace of evolutions therefore limiting the capability of comparison for analysts, or mapping all data in a given version of the structure that entails alteration (or even loss) of data [2]. The following example shows two different spatial dimensions resulting of the Soviet Union's division in many smaller countries.

In 1991 when Soviet Union was unified.
In 1994 after the Soviet Union's division, 15 new countries were created (ex. Federation of Russia, Armenia, Ukraine).

Many studies have been proposed to handle some of these issues:

  • The updating models focus on mapping data into the most recent version of the structure;
  • The tracking history models keep trace of evolutions of the system. Some choose to represent data in the temporally consistent mode of presentation. Therefore these models are not able to draw comparisons across time.
  • The unchanged structure models are aware of the users' needs of both accurately tracking history and comparing data, and provide a way of mapping data in an “unchanged structure”, chosen by the user.

Some combined approaches, like the one proposed by Body et al [2],[3], lay down bases for handling evolutions in multidimensional structures with the exploitation of the knowledge on evolutions in order to map data in a given representation.


Support for automatic cartographic generalization or multiple cartographic representation of elements

When one needs to have a more global cartographic view of a phenomenon, it is often not possible to simply aggregate spatial data since the map or display becomes overcrowded and unreadable. One must rather use map generalization processes. According to Weibel and Dutton [4], “Map generalization is responsible for reducing complexity in a map in a scale reduction process, emphasizing the essential while suppressing the unimportant, maintaining logical and unambiguous relations between map objects, and preserving aesthetic quality”. Every map, including the map made from source data, uses some level of generalization. By definition, a map is a model of only a subset of the reality where unnecessary details are eliminated and useful data emphasized while maintaining the map's readability. Going from a large map scale to a smaller map scale worsens the situation. Categories of objects as well as individual objects are eliminated, others are replaced by a symbol of larger or smaller size, some are displaced, their shape is simplified, topological relationships may change, groups such as “building blocks” replace individual buildings where the density is too high, and so on. In other words, the content of every map may lie, the measurements made on every map may lie and a topological relationship on every map may lie. The following example shows the spatial aggregation-generalization mismatch where aggregated data provide true data but unreadable map (on the left) while generalized data produce readable map but inexact data (on the right). The user of a SOLAP tool must be aware of that fact when zooming or drilling on a map.

Example of spatial aggregation-generalization mismatch. [5]

In certain occasions, the representation of objects at smaller scales can be purely symbolic (i.e. generalized to the highest degree). For example, in an origin-destination analysis context, the origin and destination points can be linked by straight lines instead of the actual roads, like in the figure below. This concept can be called symbolic generalization.

Example of symbolic vectors representing origin-destination data. [5]

In the context of interactive web applications such as SOLAP applications, response times must be very fast. Because most cartographic generalization processes are complex and still require human intervention, they can not be conducted on-the-fly. A solution is to store the precomputed generalizations in what is called a multiple representations database. A multiple representations database can be described as a spatial database, which can be used to store the same real world phenomenon at different levels (that are linked) of thematic and geometric detail.


[1] Body, M., M. Miquel, Y. Bédard & A. Tchounikine, 2003. Handling Evolutions in Multidimensional Structures, IEEE 19th Int. Conf. on Data Engineering (ICDE), March 5-8th, Bangalore, India.

[2] Body, M., M. Miquel, Y. Bédard & A. Tchounikine, 2002. A Multidimensional and Multiversion Structure for OLAP Applications, Proceedings of the ACM Fifth International Workshop on Data Warehousing and OLAP, pp. 1-6,

[3] Rivest, S., Y. Bédard, M.-J. Proulx, M. Nadeau, F. Hubert & J. Pastor, 2005. SOLAP: Merging Business Intelligence with Geospatial Technology for Interactive Spatio-Temporal Exploration and Analysis of Data, Journal of International Society for Photogrammetry and Remote Sensing (ISPRS) "Advances in spatio-temporal analysis and representation", 60 (1), pp. 17-33.

[4] Weibel, R. & G. Dutton, 1999. Generalizing Spatial Data and Dealing with Multiple Representations. In P. Longley, M. Goodchild, D. Maguire & D. Rhind (Eds.), Introduction. Geographical Information Systems: Principles and Technical Issues, pp. 125-155.

[5] Bédard, Y., S. Rivest, & M.-J. Proulx, 2007, Spatial On-Line Analytical Processing (SOLAP): Concepts, Architectures and Solutions from a Geomatics Engineering Perspective, In: Robert Wrembel & Christian Koncilia (Eds.), Data Warehouses and OLAP: Concepts, Architectures and Solutions, Chap. 13, IRM Press (Idea Group), London, UK, pp. 298-319.

[6] Proulx, M.-J., Bédard, Y., 2008, Fundamental Characteristics of Spatial OLAP Technologies as Selection Criteria, Location Intelligence 2008, April 29, Santa Clara, CA, USA.

Université Laval - Canada
Updated: November 2009