ISPRS, Vol.34, Part 2W2, "Dynamic and Multi-Dimensional GIS”, Bangkok, May 23-25, 2001
229
jmers and
nformation
iders must
standards,
nformation
¡onnection,
e software
xecuted on
i extremely
lost of the
s not the
The other
5 WMT is
: cascading
p server. In
¡sources of
architecture
;e the client,
th different
omminuting
nely heavy,
ach can be
irs in the
r server is a
lediator has
of data,
oh between
load on the
providers to
e mediator
srs, but also
>m different
of Spatial
ot with the
e catalogue
customer,
’s catalogue
tablish their
WFS server,
jeographical
the Spatial
;tiveX viewer
Information
sr GML or
ler. SVG is a
Wide Web
i to XML for
[13]. With a
-n of GML. If
service, the
SVG to user
omer. If the
ing, GML is
ir is the other
GIService in
afits from the
ndards offer
ecification on
new concept
and acquiring
le to limit the
e, there is no
i marketplace
ore flexible to
, a common
services from
Customers
Spatial Information
Marketplace Server
Customers
Other Marketplaces
Query service / Function
service
Catalogue service
(Common data model for
Figure 2. Architecture of Spatial Internet Marketplace
5. EXTENSIONS TO OGC’S STANDARDS
This section describes the extensions to the OGC simple feature
specification to accomplish the vision of Spatial Internet
Marketplace.
There is no suitable class in the simple feature specification for
services. Moreover, specifications on getmap, getfeatureinfo and
getcapabilities in WMS are too primitive to be considered as the
common requesting language. Different service providers offer
different methods to access a spatial feature. For example, there
are many ways to get a feature: by its location; by its special
attributes and by its spatial relationship to other features. This is
impossible to extend the standard to cope with all those methods,
even in the later phases of WMS. Instead of extending existing
classes, this section defines new general classes and requesting
language for services to the standards.
5.1 Common data model for services
Design philosophy behind the data model of the spatial
information market is making use of the existing standards with
minimal modifications. Figure 3 illustrates the proposed data
model. The data model extends the OGC’s simple feature
specification and the OGC’s catalog specification. Text blocks
bounded by heavy lines represents new classes to the existing
standards.
The major modification is to extend the concept of feature to the
concept of service. Servicefeature, which is a subclass of feature,
is a new class to the simple feature specification. This class is an
abstract representation of all services. Servicefeature is a spatial
object since it contains spatial element that represents its valid
locations / areas. The class provides interfaces to communicate
with the mediating server while a common language, which will be
mentioned in the following sections. Attributes of the service, for
examples, default parameters and attribute constraints. This
class acts as the wrapper in the overall architecture of the
marketplace. The Servicefeature contains interface to receive
requests from the mediator. On receiving the requests, the
Servicefeature issues server-dependent commands to its
sub-classes: Queryservice and Functionservice.
Queryservice and Functionservice represent the implementation
details of the services, and they are isolated from both the
customers and the mediating server. As the name implied,
Queryservice is an abstract class for data querying service. The
class associates to a Feature class object (or its sub-class, such
as FeatureCollection), the object is the input data set of the
service. The Queryservice provides interfaces to execute the
querying operations, and the operations are coded with its own
machine-depended language. Functionservice class has similar
structure as the Queryservice class, although this class
associates two sets of Feature class objects. One of the Feature
class objects represent the input data set and the other
