ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS’’, Bangkok, May 23-25, 2001 
228 
Geographical information interoperability is arisen from the needs 
of integrating and sharing the huge amount of geo-data from 
various sources. Open GIS Consortium (OGC) is the most active 
organization that develops industry-wide agreed standards for 
interoperable geoprocessing. OGC’s goal is to develop a unified 
framework for geo-spatial information communities. Hence, the 
communities adopt common mean to represent the Earth digitally; 
to implement geo-spatial data manipulation; and to solve 
institutional non-interopability problems [2]. Important standards 
to the Spatial Information Marketplace include; 
• OpenGIS Simple Features Specification is the fundamental 
standard that deals with the representation and 
manipulation for features on the earth surface. 
Implementation specifications have been developed for 
OLE/COM, COBRA and SQL [5], [6], [7]. 
• Catalog service and information community [8] 
• OpenGIS Web Map Server (WMS) Interface 
Implementation Specification - a standard for publishing 
maps on the Internet [9]. 
• OGC Web Feature Server (WFS) is a feature-based version 
of WMS. This specification will be developed in the second 
phase of WMS. 
• WFS Filter interface specification - standard querying 
language for WFS. This specification will be developed in 
the second phase of WMS. 
• Geography Markup Language (GML) - standard 
description of geographical features for data transportation 
and storage, this is an extension of Extended Markup 
Language (XML) [10]. 
The standards are contributed and agreed by major GIS software 
vendors in the industry, for examples, ESRI, Intergraph, Autodesk 
and Oracle. Details of those standards can be found from the 
OGC's Web site (http://www.openqis.org). 
4. PUTTING THEM TOGETHER: ARCHITECTURE OF 
SPATIAL INFORMATION MARKETPLACES 
Referring to the available technologies of geographical 
information interoperation, this section proposes an integral 
architecture of the Spatial Information Marketplace. The proposed 
marketplace consists of host of the marketplace, service provider, 
data communication between providers and customers, and 
wrapper at each service provider. 
Figure 1a. Parallel access, 1b. Cascading access, 
Data communication and data sharing among customers and 
services providers are critical to the Spatial Information 
Marketplaces. Hence, servers of various service providers must 
be efficiently connected. With referring to the OCG's standards, 
several possible architectures of the Spatial Information 
Marketplace are proposed [11]. Those are, direct connection, 
cascading server and mediating server (Figure 1). 
In the architecture of parallel access (Figure 1a), the software 
module that co-ordinates all the service providers is executed on 
the client-side. Computational loading for the client is extremely 
heavy, moreover, there is no server acts as the host of the 
marketplace. Consequently, the parallel access is not the 
anticipate architecture for the marketplaces. The other 
architecture, which is suggested by OGC in the WMT is 
cascading access [9] (Figure 1b). The architecture of cascading 
access treats map server as the client of another map server. In 
the client point of view, this approach integrates resources of 
multiple servers to one location on the Internet. This architecture 
is not enough for the adequate to the marketplace, since the client, 
responds for communicating service providers with different 
interfaces, input and output data formats and comminuting 
language. Hence, workload at the client side is extremely heavy. 
However, to accomplish a complex task, this approach can be 
applied to co-operate different service providers in the 
marketplace. Among the three architectures, mediator server is a 
more appropriate architecture for the marketplace. Mediator has 
been suggested to manipulate huge volumes of data, 
heterogeneities among data resources and mismatch between 
data values [12] (Figure 1c). To reduce computational load on the 
client side, mediator is used to co-ordinate all service providers to 
accomplish a service required by customer. The mediator 
ensures not only parallel access to all services providers, but also 
data compatibility between data sets received from different 
providers. 
Figure 2 illustrates the proposed architecture of Spatial 
Information Marketplace, customers firstly interact with the 
service providers through the catalogue service. The catalogue 
stores descriptive information of services to customer. 
Implementation of the catalogue shall follow the OGC’s catalogue 
implementation specification. Service providers establish their 
services according to the standardized OCG WMS or WFS server. 
GML should be the media for exchanging of geographical 
information between these service providers and the Spatial 
Information Marketplaces. 
On the client side, customer equips with a simple ActiveX viewer 
and Internet browser to access the Spatial Information 
Marketplace Server. The Server provides either GML or 
Scaleable Vector Graph (SVG) data set to the customer. SVG is a 
standard graphic format developed by World Wide Web 
Consortium (W3C), the format is another extension to XML for 
exchanging two-dimensional graph on the Internet [13]. With a 
Map Style Sheet, SVG can use as a visualizing form of GML. If 
the customer interests in the graphic result of the service, the 
Spatial Information Marketplace server generates SVG to user 
with the Map Style Sheet requested by the customer. If the 
customer requires the result for further processing, GML is 
delivered to the customer. A special type of customer is the other 
Internet-based Marketplace, which requires Gl and GlService in 
its own business using the format of SVG. 
The proposed spatial information marketplace benefits from the 
existing standards developed by OGC. The standards offer 
fundamental spatial data exchange formats and specification on 
Internet map server. However, the marketplace is a new concept 
to the OGC’s standards, specifications on service and acquiring 
methods are required to develop. This is impossible to limit the 
type of services available in the marketplace, hence, there is no 
way to standardize all types of services. Rather, the marketplace 
demands a common data model for service that is more flexible to 
represent disparate types of services. Moreover, a common 
requesting language is required to access those services from 
different providers [4], [14].