Specifying the Computation Viewpoints for a Corporate Spatial Data Infrastructure Using ICA’s Formal Model

Abstract

Spatial Data Infrastructure (SDI) is a concept that aids in discovering, sharing, and using geospatial data. Nevertheless, given the breadth of this concept, several ways of developing SDI have emerged. The International Cartographic Association (ICA) has proposed a formal model to describe SDIs irrespective of technologies and implementations by using three of the five viewpoints of the RM-ODP framework. However, the use of ICA’s model to describe corporate SDIs had not been assessed yet. Companhia Energética de Minas Gerais (Cemig) seeks to develop an SDI, called SDI-Cemig, to facilitate the discovery, sharing, and use of geospatial data by its employees and partner companies. This study describes the specification of SDI-Cemig’s components using the Computation viewpoint of ICA’s formal model, which proved adequate. Although a single case study does not validate the model for every corporate SDI, this study showed that it can be used for this type of SDI.

1 Introduction

Geospatial data are data referenced on Earth’s surface and are essential in the decision-making process of an organization. However, according to [10, 13], geospatial data are a costly resource given the time and funds required to obtain them. The concept of Spatial Data Infrastructure (SDI) has emerged to help public and private organizations cut down costs in obtaining and using geospatial data.

Rajabifard and Williamson [13] define SDI as a stable environment formed by technologies and contributions, which the users employ to reach their goals. Harvey et al. [7] consider the SDI a concept that improves the sharing and use of geospatial data and services, which helps different users of a given community. Such communities may be organized hierarchically, as shown in Fig. 1, which facilitates sharing among communities.

Fig. 1.

SDI hierarchy – adapted from [5,13]

According to [8], the SDI concept is very broad, leading to different ways of development, both technical and organizational, which is also pointed out by [3]. In order to guarantee that the basic SDI concepts in the literature are contemplated during the specification phase, the International Cartographic Association (ICA) has developed a model to describe SDI irrespective of technologies or implementations using the concept of viewpoints from the RM-ODP (Reference Model for Open Distributed Processing) framework [8]. This model was later extended by Cooper et al. [4], Béjar et al. [1], and Oliveira and Lisboa-Filho [12].

Nonetheless, ICA’s formal model for SDI has not been assessed in the development of corporate SDIs. Companhia Energética de Minas Gerais (Cemig) is a mixed-economy conglomerate controlled by the government of the state of Minas Gerais, Brazil, comprising over 200 companies. Cemig uses and produces large amounts of geospatial data. However, such data are currently documented and used in a non-standardized way within the company, with hinders sharing and discovering them.

The present study presents part of the SDI specification under development at Cemig (called SDI-Cemig), particularly the Computation viewpoint, using ICA’s formal SDI model in order to verify whether this model is able do describe a corporate SDI. The other viewpoints approached by ICA’s model (Enterprise and Information) will not be targeted by this study.

The remaining of the paper is structured as follows. Section 2 describes ICA’s formal SDI model while detailing the Computation viewpoint. Section 3 presents the specification of the Enterprise viewpoint for SDI-Cemig. Section 4 discusses the results presented in this study and, finally, Sect. 5 presents the final considerations.

2 ICA’s Formal SDI Model

According to [8], ICA’s formal SDI model (henceforth referred to as ICA model) describes the SDI concepts irrespective of technologies or implementations using the RM-ODP framework.

RM-ODP, according to [6, 9, 14], is an architectural framework standardized by the ISO/IEC (International Organization for Standardization/International Electrotechnical Commission) used to specify heterogeneous distributed-processing systems. In order to facilitate the specification, RM-ODP uses the concept of viewpoints.

RM-ODP uses five viewpoints: Enterprise, Information, Computation, Engineering, and Technology. The use of viewpoints allows the system to be specified into smaller models, where each viewpoint answers relevant questions for different users of the system [9, 14]. Figure 2 presents the relationships among the five viewpoints in RM-ODP.

Fig. 2.

Viewpoints of the RM-ODP framework and their relationships – adapted from [8]

The Enterprise viewpoint details the system’s requirements and policies. The Information viewpoint details the semantics, behavior, and restrictions – which may be the policies of the Enterprise viewpoint – of the data in the system [6, 8]. According to [9], the Computation viewpoint describes the system components. However, the physical distribution of the components is not described in the Computation viewpoint, but instead in the Engineering viewpoint. Finally, the Technology viewpoint describes the technological artifacts described in the other viewpoints.

ICA’s model describes only the viewpoints Enterprise, Information, and Computation. According to [3, 8], the other viewpoints heavily depend on the implementation and are not considered in ICA’s model. The Computation viewpoint in ICA’s model is detailed in the next subsection. The Enterprise and Information viewpoints will not be detailed since they are not relevant for this study.

2.1 Computation Viewpoint

According to [3], the Computation viewpoint “is a functional breakdown of the system modeled in a set of objects that interact through interfaces.” However, during the modeling of the objects that make up the system, their physical distribution must not be considered, which will be in the hands of the Engineering viewpoint.

The RM-ODP framework determines that the interfaces of the computing objects must have a signature, a behavior, and an environment contract. To simplify the model, the behavior of the interfaces was modeled using the interfaces provided and required in the diagram and components of the UML, while the signatures and environment contracts have not been described [3].

Cooper et al. [3] identified six computational objects required in an SDI, as shown in Fig. 3: SDI Data; SDI Portrayal; SDI Registry; SDI Processing; SDI Application; and SDI Management. Each of these computational objects uses and provides a set of features through the interfaces, and their relationships are shown in Fig. 3. The connectors that have a circle are the interfaces provided, i.e., the features offered by the components. The connectors that have an arc are the required interfaces, i.e., the features the component needs to carry out one or more task and that are provided by other components.

Fig. 3.

Diagram of components for computational objects of the SDI – [3]

The SDI Registry is the component responsible for storing and registering the products (data and services), catalogs, metadata, product specifications, and SDI policies, besides allowing them to be searched. The component has a single required interface, SDI Management::Control, and three provided interfaces. According to Cooper et al. [3], the notation “::” indicates the interfaces of a component. Since all components use the SDI Management::Control interface, it will be omitted when the required interfaces of a component are described. The SDI Registry::Register interface is responsible for providing the features of the information an SDI may have. The SDI Registry::Search interface seeks the information required by the users through the catalogs registered in the SDI, while the SDI Registry::Publish interface publishes the information registered on the internet and other media, which allows the user to search for the information registered in the SDI.

The SDI Data component manages the datasets that have been shared and registered on the internet and has a single provided interface. SDI Data::Data Delivery is responsible for sending the data requested by the SDI Application and SDI Processing components. The data are requested after a search is performed using the SDI Registry::Search interface. The SDI Data component requires the interfaces SDI Registry::Publish and SDI Registry::Register since it is only able to deliver the data that are registered and published in the SDI. The component SDI Processing is responsible for processing the SDI data, containing services such as transformation of geographic coordinate systems, data analysis, and coordinate processing. Similarly to SDI Data, SDI Processing has a single provided interface, SDI Processing::SDI Delivery, which allows the other components to use the processing services offered by the component or SDI. SDI Processing uses the following interfaces: SDI Data::Data Delivery to obtain the data used by the processing services; SDI Registry::Publish and SDI Registry::Register to automatically publish and register new geospatial data generated by the processing services; and SDI Registry::Search, used to search for new data whenever needed.

SDI Portrayal shows the geospatial data as static images when requested by the component SDI Application. It has a single provided interface, SDI Portrayal::Portrayal Delivery and requires the interfaces SDI Registry::Register and SDI Registry::Publish. The component SDI Application is considered by Cooper et al. [3] the main component of the SDI and is the only component accessed by the user. In order to meet all the user’s needs, SDI Application requires several interfaces and uses, at least, one interface from each of the other components, as shown in Fig. 3, besides not having any provided interface. The last component is SDI Management, which guarantees the other SDI components work through the interface SDI Management::Control as a guarantee of interoperability among the services and access rights of each user.

The authors of this study, however, disagree with some interfaces and relationships among the components proposed by [3]. The components SDI Portrayal and SDI Data use the interfaces SDI Registry::Publish and SDI Registry::Register, which do not match the features of the respective components. As described, the component SDI Data is the only one with direct access to the database and is responsible for delivering the data searched to the user. Since it carries out only this function, the component does not need to register or publish the data. Moreover, since it is the only component that accesses the database, SDI Data must provide an interface to handle (create, update, and remove) data from the SDI. Therefore, the interface SDI Data::Data Manipulation was added for data handling. The SDI Portrayal component returns the geospatial data searched such as maps, i.e., in the form of static images. In case the user wants to register or publish the map returned, it is the component SDI Application, and not SDI Portrayal, that must take up this responsibility. This way, both SDI Data and SDI Portrayal become more independent from SDI Registry, which facilitates its maintenance and use by other SDIs.

The component SDI Processing, however, kept the required interfaces SDI Registry::Register and SDI Registry::Publish for the sake of efficiency and, for the same motive, got the interface SDI Data::Data Manipulation. In case the services are chained, i.e., several services are executed in sequence with little or no user intervention, e.g., whether a service needs the previous service to publish the data processed to access them, that can be done with no need for going through the component SDI Application. Figure 4 presents the components adapted from the Computation viewpoint, which will be used in the remainder of this paper.

Fig. 4.

Diagram of adapted components of the computation viewpoint

3 SDI-Cemig

As described in Sect. 1, the Cemig corporation seeks to standardize the use and sharing of data and geospatial services in the company conglomerate by developing and using SDI-Cemig.

The model by the ICA was used to specify SDI-Cemig so as to guarantee that the basic SDI concepts in the literature would be contemplated during the specification phase. Subsect. 3.1 describes the Computation viewpoint in ICA’s model applied to the specification of SDI-Cemig. As mentioned earlier, the Enterprise and Information viewpoints are not detailed since they do not belong to the scope of this study.

Computation Viewpoint

The Computation viewpoint is detailed by comparing the components specified by Cooper et al. [3] to the computational objects in SDI-Cemig. Moreover, Subsect. 3.1 details the computational objects by specifying their interactions with other objects and their required and provided interfaces.

Figure 4 presents the basic components an SDI must have and the relationships among their interfaces. These components can be considered abstractions of the computational objects and represent a set of computational objects that have similar functionalities. The applications and services to be used by SDI-Cemig have not been defined yet, however, it has been defined that any application to be used must be compatible with the standards of the Open Geospatial Consortium (OGC). For this reason, the following generic names will be used to represent the components of SDI-Cemig: Portrayal_SDI-Cemig; Data_SDI-Cemig; and Catalogue_SDI-Cemig. It was verified whether these components behave similarly to those proposed in [3].

The component Portrayal_SDI-Cemig implements the Web Map Service (WMS) standard, responsible for generating the maps with static images from the geospatial data provided by the application. The component Data_SDI-Cemig is in charge of accessing the geospatial data of SDI-Cemig and is able to recover, input, change, and delete such data while implementing the standards Web Feature Service (WFS), Web Feature Service-Gazetteer (WFS-G), and Web Coverage Service (WCS). Finally, the metadata [2] and catalogs are managed by the component Catalogue_SDI-Cemig, which used the OpenGIS Catalogue Service standard. As well as the component Data_SDI-Cemig, Catalogue_SDI-Cemig is able to recover, input, update, and delete the catalogs and metadata from SDI-Cemig’s database.

The component SDI Application is the only one accessed by the user and has no provided interface. However, it has several required interfaces to meet the user’s needs. In SDI-Cemig, this component is equivalent to a Geoportal. Geoportals, according to Tait [15], are user access points to geographic content in the network, either the internet or intranet. Thus, in SDI-Cemig, the Geoportal aims to serve as a user access point to the features and data in the SDI, which are provided by the geospatial services.

The component SDI Portrayal is responsible for showing the data and results of the operations to the user when requested by the component SDI Application, thus providing a single interface to make this feature available. In SDI-Cemig, it is Portrayal_SDI-Cemig that plays this role. Just as the component proposed by Cooper et al. [3], Portrayal_SDI-Cemig has a single provided interface, which is responsible for providing a graphical representation, i.e., a map that presents the data provided to the component.

The access to and direct recovery of data in the SDI, a responsibility of the component SDI Data, corresponds, in SDI-Cemig, to the component Data_SDI-Cemig. Data_SDI-Cemig has interfaces that allow the geospatial data requested to be recovered, while the way this request is fulfilled is differentiated. Using the interfaces standardized by the WFS, the component Data_SDI-Cemig recovers geospatial data through spatial queries, while in the interfaces standardized by the WFS-G standard, the data are recovered using a geographic dictionary called gazetteer. However, neither standard specifies interfaces able to recover georeferenced images, a feature that is the responsibility of the interfaces standardized by the WCS standard. Data_SDI-Cemig implements the interfaces of the WCS standard in a similar way as those in the WFS standard, i.e., allowing the coverage data (images and matrices) to be recovered through spatial queries.

The component SDI Registry is responsible for registering the SDI’s data and services in catalogs to facilitate searching for and recovering them. Catalogue_SDI-Cemig is equivalent to this component in SDI-Cemig. As in the component specified by Cooper et al. [3], Catalogue_SDI-Cemig has interfaces to register and search the catalogs and their records by implementing the interfaces specified by the OpenGIS Catalogue Service. However, it is noteworthy that the SDI Registry::Register interface guarantees the catalogs and their records are input or updated in the database, but not that they are available to the user. In order for a catalog or record to be available to the user, either via internet or intranet, the interface SDI Registry::Publish must be used. Nevertheless, Catalogue_SDI-Cemig has no specific interface for this task, which requires adapting an application or service compatible with the standard. The adaptation can be done by adding a new interface or feature, which is equivalent to the interface SDI Registry::Publish, or by changing the behavior of the interface SDI Registry::Register in a way that, when a new catalog or record in registered, it will automatically become available to the user. This last possibility was the one chosen to apply the function of the interface SDI Registry::Publish to the component Catalogue_SDI-Cemig.

Initially, SDI-Cemig will not have geoprocessing services since its focus is to facilitate sharing geospatial data relevant to Cemig’s employees and clients. Moreover, SDI-Cemig has no specific component to deal with the management of data access rights and to guarantee the integrity and compatibility of the geospatial data in the exchange of messages among the interfaces. The management of access rights will be the role of the Geoportal, while data integrity and compatibility will be guaranteed by the components themselves. Therefore, SDI-Cemig has no component equivalent to SDI Processing or SDI Management.

3.1 Computational Objects of SDI-Cemig and Their Interfaces

According to Linington et al. [9], the Computation viewpoint is responsible for modeling the basic features of an application by specifying the services the application offers through components and their interfaces with no concern about the physical distribution of these components or which technologies will be used to implement them.

Figure 5 presents a simplified version of the components identified in SDI-Cemig and their interactions through computational objects (CV_Object), their interactions with other computational objects, and the packages that group them. According to Linington et al. [9], “computational objects encapsulate part of the system’s status and functionality, thus enabling a modular system modeling.”

Fig. 5.

Simplified view of the computational objects in SDI-Cemig

The computational objects in SDI-Cemig can be grouped into four groups: Human_Objects, which represent the actors specified in the Enterprise viewpoint; Presentation_Objects, representing the interfaces used by the actors; Application_Objects, whose computational objects represent the features and, consequently, the components offered by SDI-Cemig; and Data_Management_Objects, which access the database to recover, input, change, and delete the data requested by the computational objects of the package Application_Objects.

Figure 6 presents the computational objects in more details, with their provided and required interfaces and their interactions. Since the computational objects of the package Human_Objects (User, Provider, Operational Body, and Cataloguer) represent system actors, they have a single required interface, which interacts with the specific interfaces of each actor in the Geoportal. Moreover, the computational object group Human_Objects is responsible for connecting the Enterprise and Computation viewpoints, as shown in Fig. 2.

Fig. 6.

Computational objects in SDI-Cemig

The actors used as computational objects were chosen because, in order to carry out their functions, they depend on the features offered through the OGC standards. The Geoportal interfaces of each actor require the interfaces of the computational objects from the Application_Objects package that meet their needs.

ICA’s model and its extensions define several possible actors an SDI can have, and the main ones are: User; Governing Body; Producer; Provider; Broker; Value-Added Reseller; and Operational Body. The description of each actor, along with their specializations, can be found in [3, 4, 8, 12].

In this section, the symbol * indicates that a provided interface (e.g., GetCapabilities_*) is equivalent for the WFS, WFS-G, and WCS standards. Catalogue Service standard was not included due to its particularities. The interface GetCapabilities_*, when used, returns a list of features offered by the component and their respective descriptions. Thus, when an object requests this interface, it can check which other features it can access and how to access it. The provided interface Transaction_* allows inputting, updating, and deleting data of the type of data the computational object focuses on. Besides these interfaces, each computational object in the package Application_Objects offers a specific set of provided interfaces. The provided interfaces of the computational object Data_SDI-Cemig are specified by the standards WFS, WFS-G, and WCS: GetPropertyValue_WFS; GetFeature_WFS; DescribeCoverage_WCS; GetCoverage_WCS; GetFeature_WFS-G; DescribeFeatureType_WFS; DescribeFeatureType_WFS-G; GetCapabilities_*; and Transaction_*.

The interface GetPropertyValue_WFS returns the value of a property or part of a complex property of a search feature. GetFeature_WFS returns one or more geographic features according to the search performed. DescribeFeatureType_WFS returns a schema containing the types of features offered by the service, besides specifying the standards the data must have to be used by the service.

The interfaces specified by WFS-G are the same specified by WFS, and they also behave similarly. The difference between their interfaces is the way the searches are performed. While WFS specifies that the recovery of geographic features is performed through searches that use spatial operations, such as the use of a minimum bounding rectangle, feature overlap, etc., the interfaces specified by WFS-G determine that the features are recovered by using gazetteers.

In case the user wants to recover coverage data from the SDI, the interfaces from the WCS standard implemented by Data_SDI-Cemig must be used. The provided interfaces related to the WCS standard are similar to those in the WFS and WFS-G standards. The interface DescribeCoverage_WCS returns a description of the coverage data the SDI has, including, for example, the area the data comprehends, what it represents, and its structure. The coverage data is returned to the user through the interface GetCoverage_WCS. As in the interface GetFeature_WFS, the data is recovered based on queries that use spatial concepts.

Since Portrayal_SDI-Cemig is a computational object that does not change the geospatial data in the database, it has no required interface and, therefore, does not interact with the computational object of the package Data_Management_Objects.

The last computational object described in the package Application_Objects is Catalogue_SDI-Cemig. This computational object is responsible for recovering and handling the geographic catalogs in SDI-Cemig. The provided interfaces GetRecordbyID_CS and GetRecords_CS return the catalogs that meet the criteria of the search performed by the user. The difference between the two interfaces is the way the catalog is searched and the amount returned. In the interface GetRecordbyID_CS, a single catalog is returned in case it has the same identifier as the one searched, while the interface GetRecords_CS will return all catalogs that meet the criteria of the search performed. The last interface, Harvest_CS, is responsible for inputting the catalogs and their records in SDI-Cemig, as well as the interface Transaction_CS. However, the interface Harvest_CS performs this function by “harvesting” the catalogs and records from other databases and referencing them in SDI-Cemig. In other words, while Transaction_CS inputs the user-provided catalogs and records provided into SDI-Cemig’s database, Harvest_CS references in SDI-Cemig the catalogs and records from other databases, making them available to the user.

Since the computational objects Data_SDI-Cemig and Catalogue_SDI-Cemig handle data present in SDI-Cemig’s database, they need required interfaces which interact with the computational objects of the package Data_Management_Objects. Data_SDI-Cemig inputs, updates, deletes, and recovers the geospatial data requested by the user. Hence, this computational object uses the provided interfaces Management_Vectors and Management_Rasters.

However, one policy in SDI-Cemig states that “the metadata must be stored along with the data they describe”. Therefore, the metadata must be stored when the geospatial data are input or changed in the SDI. The computational object Catalogue_SDI-Cemig is responsible for maintaining the metadata and its required interface interacts with the provided interface Metadata_Management and Catalogue_Management. The interface/computational object Metadata_Management allows Catalogue_SDI-Cemig to input, update, delete, and recover the metadata of the geospatial data, while the interface computational object applies these same features to the catalogs, which maintain the metadata as records.

Figure 7 highlights the possible computational objects and interfaces the actor User may use in SDI-Cemig. The interface presented to the user when he or she accesses SDI-Cemig through the Geoportal allows the user to search for geospatial data through spatial queries, geographic names, or by browsing the catalogs, and then the data can be visualized and/or recovered.

Fig. 7.

Computational objects and interfaces used by the user

In order to perform queries, the user interface (Geoportal_User) requires the interfaces GetRecords_CS and GetRecordbyID_CS. These interfaces return the metadata catalogs of the geospatial data, which can be searched so that the user finds the data that meets his or her needs. In case the user finds in the metadata the data of interest, he or she can recover them using the interfaces GetFeature_WFS, GetFeature_WFS-G, and GetCoverage_WCS. Besides recovering them, the user may visualize the geospatial data on the browser itself using the interface GetMap_WMS by forwarding to this interface the data to be visualized.

The interface GetCapabilities_* is designed for users who want to use SDI-Cemig’s features with no need to access it via a web browser. This interface returns the features offered by the computational object, besides the information that aids in the use of these features.

The other actors in the package Human_Objects will not be detailed as the actor User in Fig. 7 because this detailing can be inferred from Fig. 6, while Fig. 7 was used to exemplify how this detailing is performed. Finally, if needed, the detailing of the other actors can be found in [11].

4 Discussion of Results

The Computation viewpoint in ICA’s model for SDI proved appropriate to describe the components in SDI-Cemig. The changes applied to the model increases the independence among the components, which facilitates specifying, maintaining, and using them. That occurs because, as each component only offers and requires interfaces directly related to its function, in case a component stops working, the operation of the components will not be affected. Furthermore, the component SDI Application on the ICA’s model needs further discussions. For example, is it necessary to represent the component’s feature chain service? If yes, how will that be represented?

Although the SDI-Cemig doesn’t have a component equivalent to the component SDI Management of the ICA’s model, the authors of this study recommend strongly the implementation of the component SDI Management. The SDI Management implementation allows that the access permissions and interoperability of data and services are guaranteed whether users and systems outside of the Cemig’s environment access the web services (accessed through the component SDI Application).

Through the specification of the Human_Objects, it can be verified that, at least for SDI-Cemig, only a small set of possible actors an SDI may have compulsorily needs its computational features to carry out its role. The actor Governing Body, for example, defines the scope, policies, and funding of the SDI, which are critical aspects for any SDI to exist and does not require the use of the features presented in the Computation viewpoint.

ICA’s model for SDI describes the basic concepts in the literature for SDI at all levels. Hence, ICA’s model guarantees these concepts will be contemplated during the specification of the SDI. However, there is no description or orientation regarding how the model must be used. For instance, the viewpoints in the RM-ODP framework are related among themselves, as shown in Fig. 2. How should the relationship with the viewpoints Enterprise and Information be shown in the Computation viewpoint? And what elements or aspects of these viewpoints would be related with the Computation viewpoint?

5 Conclusions

The use of ICA’s model for SDI allowed the components and their interfaces – considered basic for an SDI to work – to be specified in SDI-Cemig. In addition, the Computation viewpoint, after being adapted, proved appropriate to describe SDI-Cemig, with no discrepancies between the model and the specification.

Although the specification of a single corporate SDI does not guarantee that ICA’s formal model is appropriate for any corporate SDI, the specification of SDI-Cemig suggests that the Computation viewpoint in ICA’s formal model for SDI can be used in corporate SDIs. Moreover, the specification presented in this specification can help other designers who wish to specify an SDI, regardless of its level or of whether ICA’s model is being used.