Geospatial Portal Reference Architecture – DRAFT OGC 04-039
i © All rights reservedOGC 2004 –
Open Geospatial Consortium Inc.
Date: 2004-07-02
Reference number of this OpenGIS®
document: OGC 04-039
Version: 0.2
Category: OpenGIS®
Discussion Paper
Editor: Louis C. Rose
Geospatial Portal Reference Architecture
A Community Guide to Implementing Standards-Based
Geospatial Portals
This Guide has been developed by the members of the Open Geospatial Consortium, Inc. to assist
the global geospatial technology community in implementing standards-based geospatial portal
solutions that are compatible with Spatial Data Infrastructures in every nation. We offer this
document as a resource for rapid development and informed acquisition of portals and portalexploiting
applications that can plug and play with geospatial data and services in your organization
and other organizations in your community and around the world.
Copyright notice
This OGC document is a draft and is copyright-protected by OGC. While the reproduction of drafts in any form
for use by participants in the OGC standards development process is permitted without prior permission from
OGC, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any
other purpose without prior written permission from OGC. We encourage distribution of this information, but
request that you ask permission.
Warning
This document is not an OGC Standard. It is distributed for review and comment. It is subject to change without
notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit
comments regarding this Discussion Paper to the author/editor(s).
The OGC invites any interested party to bring to its attention any copyrights, patents or patent applications, or
other proprietary rights, which may cover technology that may be required to practice this specification.
Please address the information to the OGC Specification Program Executive Director.
Copyright 2004 Open Geospatial Consortium, Inc. (OGC)
This document does not represent a commitment to implement any portion of this specification in any company’s
products.
OGC’s Legal, IPR and Copyright Statements are found at http://www.opengeospatial.org/about/?page=ipr&view=ipr
NOTICE
Permission to use, copy, and distribute this document in any medium for any purpose and without fee or royalty is
hereby granted, provided that you include the above list of copyright holders and the entire text of this NOTICE.
We request that authorship attribution be provided in any software, documents, or other items or products that you
create pursuant to the implementation of the contents of this document, or any portion thereof.
No right to create modifications or derivatives of OGC documents is granted pursuant to this license. However, if
additional requirements (as documented in the Copyright FAQ at
http://www.opengeospatial.org/about/?page=ipr&view=ipr_faq) are satisfied, the right to create modifications or
derivatives is sometimes granted by the OGC to individuals complying with those requirements.
THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT
THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS,
COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE
OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this
document or its contents without specific, written prior permission. Title to copyright in this document will at all times
remain with copyright holders.
RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth
in subdivision (c)(1)(ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013
OpenGIS®, OGC®, OpenGeospatial®, OpenLS® are trademarks or registered trademarks of Open Geospatial
Consortium, Inc. in the United States and in other countries.
ii © OGC 2004 – All rights reserved
Contents
Executive Summary............................................................................................................. 1
1 Introduction ................................................................................................................. 1
1.1 Terms and definitions.......................................................................................................2
2 Geospatial Portal Overview........................................................................................ 3
2.1 Geospatial Portal Description ..........................................................................................3
2.2 Service Oriented Architecture (SOA)...............................................................................4
2.2.1 Publish-Find-Bind ......................................................................................................................5
2.2.2 Self-Describing Services.............................................................................................................6
2.3 Alignment with other Reference Architectures ...............................................................7
2.3.1 OpenGIS Reference Model .........................................................................................................7
2.3.2 Federal Enterprise Architecture (FEA)......................................................................................7
2.3.3 Infrastructure for Spatial Information in Europe .......................................................................8
2.3.4 European Public Sector Information Network (ePSINet)...........................................................8
2.3.5 European Information Architecture for Public Administration..................................................8
3 Geospatial Portal Service Requirements................................................................... 9
3.1 Portal services.................................................................................................................10
3.1.1 Viewer Client............................................................................................................................10
3.1.2 Discovery Client .......................................................................................................................10
3.1.3 Publisher Client........................................................................................................................10
3.1.4 Gazetteer Client........................................................................................................................10
3.1.5 Data Extraction Client..............................................................................................................10
3.1.6 Data Manipulation Client.........................................................................................................10
3.1.7 Symbol/Style Management Client.............................................................................................10
3.1.8 Authentication and Access Control...........................................................................................11
3.1.9 Exposed Services ......................................................................................................................11
3.2 Application Integration Framework..............................................................................11
3.3 Portrayal Services...........................................................................................................11
3.3.1 Map Portrayal ..........................................................................................................................12
3.3.2 Cascading Map Reference........................................................................................................12
3.3.3 Symbol/Style Management Service ...........................................................................................13
OGC 2004 –
3.3.5 Coverage Portrayal ..................................................................................................................13
3.3.4 Map Context Encoding .............................................................................................................13
3.4 Catalogue Services..........................................................................................................13
3.5 Data Services ..................................................................................................................14
3.5.1 Feature Services .......................................................................................................................14
3.5.2 Symbology Management...........................................................................................................14
3.5.3 Gazetteer...................................................................................................................................15
3.5.4 Coverage Services ....................................................................................................................15
3.6 Procurement Issues ........................................................................................................15
4 Summary .................................................................................................................... 17
iii © All rights reserved
Figures
Figure 1. The Geospatial Portal Reference Architecture................................................................................... 3
Figure 2. Service Trading Communication Structure........................................................................................ 6
Figure 3. Geospatial Portal Reference Architecture Services Distribution........................................................ 9
Preface
This guide provides a resource to decision makers and technologists who are working to
implement geoprocessing solutions within their organizations. Whether you are a
procurement official working to procure geoprocessing technologies or a technology
provider extending existing systems or developing new technology solutions, this guide
will be an important resource.
The Geospatial Portal Reference Architecture documents a “core” set of interoperability
agreements that provide instructions for bridging the gaps between different organizations
and communities that have heretofore shared geospatial information only with great
difficulty. The portal addresses technical interoperability between diverse systems and it
also helps address "information interoperability" between groups whose content has been
created with different data models and metadata schemas.
Document Contributor Contact Points
All questions regarding this submission should be directed to the editor or the submitters:
CONTACT COMPANY ADDRESS PHONE/FAX EMAIL
Louis Rose BAE Systems 703-668-4096 louis.rose@baesystems.com
Revision History
Date Release Author Paragraph modified Description
6/29/04 0.1 Louis Rose All Re-written to be more generically
presented
7/2/04 0.2 Louis Rose All Incorporated initial review comments
from the GovSIG
Future Work
OGC welcomes improvements in this document that reflect the experience of those
implementing this service architectural framework in their own service types and instances.
iv © OGC 2004 – All rights reserved
Geospatial Portal Reference Architecture – DRAFT OGC 04-039
1 © All rights reservedOGC 2004 –
Executive Summary
The Geospatial Portal Reference Architecture documents a “core” set of interoperability
agreements that provide instructions for bridging the gaps between different organizations
and communities that have heretofore shared geospatial information only with great
difficulty. The Geospatial Portal Reference Architecture provides the basis for an open,
vendor-neutral portal that is intended to be a first point of discovery for geospatial content
in the context of designing and implementing the Spatial Data Infrastructures being
developed by over 50 nations throughout the world. In addition, the Geospatial Portal
Reference Architecture has been developed in a manner that allows it to be aligned with
other reference models and high level enterprise architectures.
The Geospatial Portal Reference Architecture is founded on the tenants of a Service
Oriented Architecture (SOA). An SOA is an architecture that represents software
functionality as discoverable services on a network yielding the following benefits:
Easier extension of legacy logic to work with new business functionality
Greater flexibility to change without the need to constantly re-architect for growth
Cost savings by providing straight-forward integration.
The Geospatial Portal Reference Architecture specifies four service classes that are needed
to procure a comprehensive geospatial portal implementation and it identifies the OpenGIS
Interoperability Standards that are applicable to the services. The four service classes are:
Portal Services –Provide the single point access to the geospatial information on
the portal. In addition, these services provide the management and administration
of the portal.
Catalog Services –Used to locate geospatial services and information wherever it
is located and provide information on the services and information if finds to the
user.
Portrayal Services –Used to process the geospatial information and prepare it for
presentation to the user.
Data Services – Used to provide geospatial content and data processing.
The Geospatial Portal Reference Architecture is a major step forward for E-Government,
National Spatial Data Infrastructures, enterprises and Information Communities. It enables
geoprocessing interoperability that make it possible to exchange heterogeneous geographic
information content and share a wide variety of geospatial services over the World Wide
Web.
Geospatial Portal Reference Architecture – DRAFT OGC 04-039
1 © All rights reservedOGC 2004 –
1 Introduction
A portal is a website that acts as gateway providing a single access point to multiple
resources. It is a web environment that allows an organization or a community of
information users and providers to aggregate and share content. It is an organized
collection of links to other sites. A portal may be secure and it may be personalized. A
geospatial portal is a human interface to a collection of online geospatial information
resources, including data sets and services.
Around the world, over 50 nations are developing Spatial Data Infrastructures (SDI). These
national activities are supported by regional collaborative efforts in Asia and the Pacific,
Europe, the Americas and Africa and in an emerging Global Spatial Data Infrastructure
(GSDI) effort. While there are many differences in economic, social and legal frameworks
around the world, the GSDI is being fueled by widespread agreement on common
approaches in many fundamental Spatial Data Infrastructure development and
implementation practices.
Through the coordination efforts of the Global Spatial Data Infrastructure Steering
Committee (now the GSDI Association), the GSDI is taking on a clear form and substance.
It consists of standardized Geospatial Metadata, a Network of Spatial Data Clearinghouses
operating on common standards-based protocols, and an emerging agreement on a set of
core data sets that will be globally available to serve as base content for SDI linkage, for
common use in spatial data applications, and for further attribution and densification for
larger scale use. The GSDI includes OpenGIS Standards as a key enabler of
interoperability between geoprocessing systems.
The philosophy and work of the various nation SDI efforts as well as the GSDI Association
are clearly in line with the Declaration of Principals from the World Summit on the
Information Society was hosted in Geneva by the Government of Switzerland from 10 to
12 December 2003. The Declaration of Principles WSIS-03/GENEVA/DOC/0004
concluded in paragraph 44:
Standardization is one of the essential building blocks of the Information Society.
There should be particular emphasis on the development and adoption of international
standards. The development and use of open, interoperable, non-discriminatory and
demand-driven standards that take into account needs of users and consumers is a
basic element for the development and greater diffusion of ICTs and more affordable
access to them, particularly in developing countries. International standards aim to
create an environment where consumers can access services worldwide regardless of
underlying technology.
This document defines the Geospatial Portal Reference Architecture that provides the basis
for an open, vendor-neutral portal that is intended to be a first point of discovery for
geospatial content in the context of designing and implementing an SDI. The reference
architecture described in this document is a general architectural framework for standardsbased
geospatial portals that provide open Web access to geospatial content and online
geoprocessing services from diverse public and private sector sources. Such portals can be
built from interoperating products supplied by vendors whose products use interfaces,
protocols, schemas, and encodings that implement OGC's OpenGIS Standards.1 The
essential requirement is that it must be "as open as the Web," open to as many other Webbased
geospatial resources as possible, through interfaces, encodings and schemas that
conform to OpenGIS Specifications.
1.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply:
binding: specific syntax and parameter values used by a client to invoke a specific server
operation
catalog: <<< First mention of a Catalog. Need a definition that includes the fact that a
Catalog is also a registry>>>
client: software component that can invoke an operation from a server or conceptual role
as originator of an operation request.
content: data or information stored in a server
feature: an abstraction of a real world phenomenon (from ISO 19107)
interface: named set of operations that characterize the behavior of an entity [OGC AS 12]
map: pictorial representation or portrayal of geographic content
operation: specification of a transformation or query that an object may be called to
execute [OGC AS 12]
request: invocation of a server operation by a client
response: result of an operation returned from a server to a client
server: actual implementation of a service or conceptual role as recipient of an operation
request.
service capabilities: service-level metadata describing the types, operations, content, and
bindings available at a service instance. Organization, classification, and presentation of
those entities may also be conveyed by the capabilities information.
service: A collection of operations, accessible through an interface, that allows a user to
invoke a behavior of value to the user (definition from ISO 19119).
spatial reference system (SRS or CRS): a projected or geographic coordinate reference
system
OGC 2004 – All rights reserved
1 OpenGIS Specifications are consensus-derived global standards for distributed geoprocessing.
2 ©
2 Geospatial Portal Overview
2.1 Geospatial Portal Description
The overall goal for Geospatial Portal Reference Architecture is to make it easier, faster,
and less expensive for any organization wishing to implement a standards based
geospatially enabled portal application. A primary objective of the reference architecture is
to define the requirements of an architectural framework that can be used as a guide to the
implementation of an operational portal that provides access to geospatial content, maps,
and metadata. This reference architecture specifies the scope, objectives and behavior of a
portal and identifies its functional components. In addition to identifying the general
requirement of an effective geospatial portal, this document highlights how OpenGIS
Standards explicitly support the capabilities of the reference architecture.
The Geospatial Portal Reference Architecture is shown in Figure 1. The reference
architecture contains five different classes of services that support the requirements of a
geospatial portal.
Figure 1. The Geospatial Portal Reference Architecture
A brief description of these service classes is presented here with more detailed
descriptions provided in section 3 of this documents:
Portal Services –Provide the single point access to the geospatial information on
the portal. In addition, these services provide the management and administration
of the portal.
3 © OGC 2004 – All rights reserved
Catalog Services –Used to locate geospatial services and information wherever it
is located and provide information on the services and information if finds to the
user.
Portrayal Services –Used to process the geospatial information and prepare it for
presentation to the user.
Data Services – Used to provide geospatial content and data processing.
It is important to understand that the Portal Services and any required Infrastructure
Services are the only ones that need be resident on the platform on which the portal is
operating. All of the other services can be distributed across the Internet and can be
dynamically registered and executed. Also notice that the Portal does not store the
geospatial data processed by the distributed services. This loosely coupled service
orientation is known as a service oriented architecture, which is described in more detail
subsequence section.
2.2 Service Oriented Architecture (SOA)2
Service orientation is a way of viewing software assets on the network—fundamentally,
the perspective of IT functionality being available as discoverable Services on the network.
Essentially, Service orientation provides business users with understandable, high-level
business Services they can call upon and incorporate into business processes as needed.
The Service orientation vision is therefore one of agility and flexibility for users of
technology, coupled with an abstraction layer that hides the complexity of today’s
heterogeneous IT environments from those users.
Service-Oriented Architecture (SOA) is an architecture that represents software
functionality as discoverable Services on the network. SOAs have been around for many
years, but the difference with the SOAs we talk about today is that they are based on
standards, in particular, Web Services. Web Services provide standards-based interfaces to
software functionality. Producers of these Services may publish information about them in
a Service registry, where Service consumers can then look up the Services they need and
retrieve the information about those Services they need to bind to them.
Applications designed using SOA can provide the same functionality as that found in a
monolithic architecture coupled with the following additional benefits:
Easier extension of legacy logic to work with new business functionality
Greater flexibility to change without the need to constantly re-architect for growth
Cost savings by providing straight-forward integration
OGC 2004 – All rights reserved
2 The 2004 ZapThink paper The SOA Implementation Framework: The future of serviceoriented
architecture Software is an excellent reference on SOA.
4 ©
Within the SOA context, therefore, the Portal is the ideal mechanism for realizing the Web
Services vision of “enter once, use often” by providing a bridge between “separate islands
of data and processing services.” The portal does not store any content. Therefore, the
geospatial content and services remain with the responsible authority- those agencies or
private sector organizations responsible for the collecting and maintaining geospatial
content continue to retain control of those activities. The authoritative source for geospatial
content and services becomes the Portal as the conduit to disparate and distributed content
and services. The OGC reference architecture is a service-oriented architecture based on
the now recognized Web Services paradigm of the publish/find/bind pattern and supports
the dynamic binding between service/content providers and requestors since sites and
applications are frequently changing in a distributed environment. Content and service
providers publish their availability to the portal’s catalog making their information
“known” to the portal.
2.2.1 Publish-Find-Bind
The core method of communications within the portal is based on service-oriented
architecture that follows a service trading paradigm. Service trading is a fundamental
concept that addresses the discovery of available service instances. Publishing a capability
or offering a service is called “export” (publish). Finding a service request against
published offers or discovering services is called “import” (Find). Binding a client to a
discovered service is called “service interaction” (Bind). This can also be depicted in an
equivalent manner as the “Publish – Find – Bind” (PFB) pattern of service interaction.
These fundamental roles and interactions are depicted in Figure 2.
This service trading function is elaborated in a separate document (ISO/IEC 13235-1) and
refined somewhat in the Object Management Group (OMG) Trading specification, which
is technically aligned with the computational view of the ODP trading function. Most
importantly, a broker supports dynamic (i.e. run-time) binding between service providers
and requesters, since sites and applications are frequently changing in large distributed
systems. A broker registers service offers from provider objects and returns service offers
upon request to requestor objects according to some criteria.
5 © OGC 2004 – All rights reserved
Broker
(Registry)
Requestor
(Client)
Provider
(Service
Provider)
(Export)
Publish
(Service Interaction)
Bind
(Import)
Find
Broker
(Registry)
Requestor
(Client)
Provider
(Service
Provider)
(Export)
Publish
(Service Interaction)
Bind
(Import)
Find
Broker
(Registry)
Requestor
(Client)
Provider
(Service
Provider)
(Export)
Publish
(Service Interaction)
Bind
(Import)
Find
Figure 2. Service Trading Communication Structure
In the portal reference architecture, there are three fundamental roles that are defined to
actuate the service trading. They are:
Broker - a role that registers service offers from service providers and returns service
offers upon request to requestor according to some criteria.
Provider - a role that registers service offers with a broker and provides services to clients.
Requestor - a role that obtains service offers, satisfying some criteria, from the broker and
binds to discovered services provided by the provider.
To export (i.e. publish a service offer), an object gives the broker a description of a service,
including a description of the interface at which that service instance is available. To
import (i.e. find suitable service offers), an object asks the broker for a service having
certain characteristics. The broker checks against the descriptions of services and responds
to the requestor with the information required to bind with a service instance. Preferences
may be applied to the set of offers matched according to service type, some constraint
expression, and various policies. Application of the preferences can determine the order
used to return matched offers to the requestor.
2.2.2 Self-Describing Services
In order for a service oriented architecture to operate in an effective and efficient manner,
the services must be self describing. That is, each service must provide a machine readable
description of its location and capabilities. This self describing information is what is
registered to the portal catalogs and enables the services to be dynamically invoked with no
modification needed to the portal software. The description of the self describing services
6 © OGC 2004 – All rights reserved
is usually based on the eXtensible Markup Language (XML). An example of a standard
that uses XML for describing a service is WSDL (Web Services Description Language).
Expressed in XML, a WSDL definition describes how to access a web service and what
operations it will perform.
2.3 Alignment with other Reference Architectures
The Geospatial Portal Reference Architecture has been developed in a generic enough
manner that allows it to be aligned with other reference models and high level enterprise
architectures. Several examples are discussed in the subsequent sections.
2.3.1 OpenGIS Reference Model
The Geospatial Portal Reference Architecture follows the tenants set forth in the OpenGIS
Reference Model (ORM)3. The ORM documents a framework of interoperability for
geospatial processing ranging from tightly coupled, real time systems on a single CPU to
the "Spatial Web" -- the open environment that enables barrier-free communication of
geographic information among users of the World Wide Web. The ORM provides the
overall conceptual framework for building geospatial processing into distributed systems in
an incremental and interoperable manner. The ORM is a living document and is updated
periodically as OGC membership continues to advance geoprocessing interoperability.
2.3.2 Federal Enterprise Architecture (FEA)4
To facilitate efforts to transform the Federal Government into one that is citizen-centered,
results-oriented, and market-based, the Office of Management and Budget (OMB) is
developing the FEA, a business-based framework for Government-wide improvement. The
FEA is being constructed through a collection of interrelated reference models designed to
facilitate cross-agency analysis and the identification of gaps, duplicative investments, and
opportunities for collaboration within and across Federal Agencies, addressing key areas
such as:
Budget Allocation;
Horizontal and Vertical Information Sharing;
Performance Measurement;
Budget / Performance Integration;
Cross-Agency Collaboration;
E-Government;
Component-Based Architectures.
OGC 2004 – All rights reserved
3 http://portal.opengeospatial.org/files/?artifact_id=3836
4 http://www.feapmo.gov/
7 ©
2.3.3 Infrastructure for Spatial Information in Europe
INSPIRE (Infrastructure for Spatial Information in Europe) is a European initiative aimed
at making geospatial content more readily available and useful for sustainable development
and increased protection of the environment. It is to be implemented throughout the
European Union (EU) over the next few years with different types of geographical
information gradually harmonized and integrated, leading to a European Spatial Data
Infrastructure (ESDI). The ESDI will deliver to users integrated spatial information
services, which cannot practically be integrated except through the standards referenced in
the Geospatial Portal Reference Architecture.
2.3.4 European Public Sector Information Network (ePSINet)
ePSINet aims to help the adoption of beneficial regulatory, standards, and information
management frameworks for Public Sector Information by providing structured access for
stakeholders in this area to:
Policy and legislation information linked to legal cases;
Innovation and good practice in the management of PSI over the whole information
lifecycle, covering back office, workflow, content and records management,
preservation, search technologies, multilingual applications and delivery channels
such as web portals, Digital TV, mobile devices and kiosks;
Developments in the related standards, especially those needed to ensure wide,
cross-domain interoperability including those related to data formats, metadata,
identifiers, terminologies, preservation, rights management, multilingual
applications and the emerging standards for the semantic web.
2.3.5 European Information Architecture for Public Administration
The InfoCitizen European Information Architecture for Public Administration is the
conceptual basis for the InfoCitizen system and its components. It contains the necessary
models and descriptions that have been developed in order to fulfill the requirements
analyzed in WP1 and that meet the goal of developing an interoperable system integrating
business processes in European Public Administrations.
The InfoCitizen European Architecture is divided into three parts:
The conceptual part, defining the business processes, information objects and the
basic interoperability mechanisms (InfoCitizen Conceptual Architecture).
The technical description, defining the structure of the InfoCitizen Platform, its
various components that compose the platform as well as the interrelationships
amongst them (InfoCitizen Technical Architecture).
The system description, detailing the software-technical consequences and
limitations exposed by the overall architecture. Also, there will be a focus on the
low level details that include the Standards Profile and the Security Profile
(InfoCitizen System Architecture).
8 © OGC 2004 – All rights reserved
3 Geospatial Portal Service Requirements
The Geospatial Portal Reference Architecture describes a framework within which an
organized collection of open standard specifications can be implemented to create spatial
content and vendor neutral "plug and play" portal infrastructures. The Geospatial Portal
Reference Architecture is also a guide for the development of affordable Web sites that
make geospatial content and geoprocessing services easily discoverable and usable and
easily integrated into larger enterprise workflows and information systems. It is explicitly
open, vendor-neutral, and not dependent on any particular geographic information system
(GIS), programming language, database, middleware or operating system. Components of
portals based on the Geospatial Portal Reference Architecture – servers, clients, servlets,
applets, middleware, databases, applications, etc. – and the external resources that link to
them can be commercial-off-the-shelf (COTS), government-off-the-shelf (GOTS), custom,
shareware, open source, and/or legacy. These components communicate through the
standard interfaces, protocols and schemas defined in the Geospatial Portal Reference
Architecture.
Figure 3. Geospatial Portal Reference Architecture Services Distribution.
In Figure 3, the Geospatial Portal Reference Architecture is presented again this time
identifying the particular services that fall within each class of service. In the subsequent
section, each of the services is discussed along with identifying which OGC
Implementation Specification is applicable for that service.
9 © OGC 2004 – All rights reserved
3.1 Portal services
The Portal Services are accessible from the Portal Platform (e.g. desktop, laptop, etc.) or
servers that have network connectivity. Users may leverage Portal Services to access the
distributed Portrayal, Catalog and Data services, depending upon the requirements and
designed implementation of the application. The access to these services is provided by
client software that is resident on the portal platform. More specifically, when accessed as
a World Wide Web application a Client runs on an HTTP server and generates HTML
pages to be displayed in the User's web browser (the thin client).
3.1.1 Viewer Client
The Viewer Client provides a visualization user interface to display and navigate content
retrieved from the Portrayal and Data services.
3.1.2 Discovery Client
The Discovery Client provides means for users to locate needed content and services
according to user-defined criteria. More specifically, the Discovery Client enables the
portal catalog containing the information about the content and services tat have been
registered to the portal to be searched and the request displayed to the user. The
Discovery Client will also allow the user to select a desired content or service and have the
service invoked for presentation in the viewer client.
3.1.3 Publisher Client
The Publisher Client provides means for portal maintainers and authorized users to publish
services or content discovered using the portal catalog. The Publisher Client allows
authorized users to register primary information sources, pre-defined symbolization rules,
and possibly other information. This published information is then made available to the
Discovery Client where the published information can be found and services invoked.
3.1.4 Gazetteer Client
The Gazetteer Client provides users the ability to navigate through spatially organized
features with well-known feature names. Gazetteer Clients allow users to formulate queries
to retrieve named features. The Gazetteer Client should utilize the USGS Geographic
Names Information System as a primary database of feature names.
3.1.5 Data Extraction Client
Data Extraction Clients provide users the ability to extract specific content from the Data
Services class of services.
3.1.6 Data Manipulation Client
Data Manipulation Clients provide users the ability to access, modify, add, and delete
geospatial content stored at remote Data Services providers.
3.1.7 Symbol/Style Management Client
Symbol/Style Management clients allow users to browse the styles available from a given
server and obtain and apply a predefined style definition for a particular feature type(s).
10 © OGC 2004 – All rights reserved
3.1.8 Authentication and Access Control
The Portal may enable Authentication and Access Control that restricts access to an
organization’s content and service offerings based on criteria that are controlled locally and
documented in the Portal site as a set of rules. At a minimum, the portal should not
prohibit Providers from defining access restrictions. In other words, the portal must not
cause all Users to appear as a single anonymous user when invoking services through the
portal.
Providers may enforce access restrictions at the network TCP/IP level, at the HTTP server
level, at the web service component level, or at any other point of the service request's
passage through the Provider's network. Providers should not be required to register their
access restrictions at the portal; however, service metadata and dataset metadata should
include information about restrictions to minimize failed access requests. Portal
participants may select and document appropriate metadata fields for this purpose.
3.1.9 Exposed Services
In addition to the client Portal client access discussed above, the Portal can also be a
service provider unto itself by furnishing Exposed Services to users, customers and client
software that is external to the portal. Basically, the Portal can be constructed to take
advantage of the access that the portal has to the content and services that have been
registered to the Portal and expose services of its own, These services can be a reflection
of the registered services, where the Portal acts as a single proxy to the many registered
services, or the Portal can offer up services that have been specifically constructed to meet
some special needs of the organization hosting the Portal.
3.2 Application Integration Framework
One of the key overall goals of the Geospatial Portal Reference Architecture is that an
instance of the reference architecture will create an Application Integration Framework
(AIF). This AIF will provide an operational environment that will have the ability to
dynamically integrate an ever expanding set of geospatial content and services into the
Portal. This capability is accomplished with the cataloging of geospatial content and
services that can be discovered by the users and dynamically evoked using tools that are
compliant with the OpenGIS Standards that enable geospatial information interoperability.
The AIF includes an integrated infrastructure to maintain and pass parameters between
OGC compliant components, as well as a client-side web-based presentation framework for
the Portal. The AIF communicates with other portal components through well-defined
software interfaces, such that different instances of such modular components could be
substituted. The AIF is able to construct valid requests to service provider such as WMS,
WFS and WCS instances to be executed either by the portal or by the user.
3.3 Portrayal Services
Portrayal Services provide specialized capabilities supporting visualization of geospatial
information. Portrayal Services are components that, given one or more inputs, produce
rendered outputs (e.g., cartographically portrayed maps, perspective views of terrain,
11 © OGC 2004 – All rights reserved
annotated images, views of dynamically changing features in space and time, etc.)
Portrayal Services can be tightly or loosely coupled with other services such as Data and
Processing Services and transform, combine, or create portrayed outputs. Portrayal
Services may use styling rules specified during configuration or dynamically at runtime by
Application Services.
Portrayal Services provide specialized capabilities supporting visualization of geospatial
information. Portrayal Services are components that, given one or more inputs, produce
rendered outputs (e.g., cartographically portrayed maps) or leverage the parameters of
rendered outputs to coordinate multi-source display (e.g. create scale and view-dependent
displays). Portrayal Services are loosely coupled with other services such as Map and Data
Services and transform, combine, or create portrayed outputs. Five possible components as
identified with the OGC Reference Architecture are described below.
3.3.1 Map Portrayal
The OpenGIS Web Map Server Specification5 (WMS) is a set of protocols that provide
access by Web clients to maps rendered by map servers on the Internet. The WMS
interface allows the client to query the “capabilities” of a given map server. Based on the
capabilities, the WMS interface allows a server to return a Portable Network Graphics
(PNG), Graphics Interchange Format (GIF), Joint Photographic Expert Group format
(JPEG), or Tagged Image File Format (TIFF) image for a given area of interest and a
specified coordinate reference system. These returned images (pictures) can be viewed in
transparency mode, thus allowing for example, the display of roads on top of a satellite
image. The WMS interface support user queries of displayed spatial content that indicates
the Spatial Reference System (SRS) and Bounding Box of the portion of the Earth to be
mapped, and the output width, height and format of the picture. The WMS can have an
addition capability to define styles that control the presentational rules that are to be used
when displaying geographic features. This ability to control the display styles in defined in
the Styled Layer Descriptors Specification6 (SLD).
3.3.2 Cascading Map Reference
The Cascading Map Server is a special case of the WMS in that it does not hold any
content of its own; rather, it serves as a gateway for other data providers, both OGCcompliant
and not. Cascading Map Servers incorporate clients for a number of services.
These clients, however, do not have to be just for OpenGIS interfaces. Legacy data
providers can be accessed, their content retrieved, adjusted, and re-presented through the
OpenGIS®
Web Mapping Service interface. As such, the Cascading Map Server can serve
a key role in presenting legacy data that may otherwise be inaccessible.
This service communicates with Provider WMS instances (both basic and SLD-enabled) to
formulate and possibly execute valid operations to request service metadata, to request
maps, or to perform other operations available from the Provider. The Cascading WMS
component can transform map formats and map projections. It allows users to discover and
OGC 2004 – All rights reserved
5 https://portal.opengeospatial.org/files/?artifact_id=5316
6 https://portal.opengeospatial.org/files/?artifact_id=1188
12 ©
select appropriate styles (either named or SLD-based) for each map layer and composes the
SLDs so that map portrayal can be requested.
3.3.3 Symbol/Style Management Service
The Symbol/Style Management Service is a multi-component system that enables map and
content retrieval, and includes the capability for creating, storing, and/or retrieving styles
and symbols from multiple communities or user groups and combining all these elements
of information into an appropriately symbolized map. This service may consist of multiple
components including a Style Registry, Style Repository, Symbol Registry, and Symbol
Repository presented through a common, standard interface. A formal description of the
Symbol/Style Management Service is currently in the change proposal process with the
OGC Specification Program as a modification to the Styled Layer Descriptors
Specification.
3.3.4 Map Context Encoding
The OpenGIS Web Map Context Specification7 allows users to save complex multi-source
presentations so they can be retrieved in total in the future so they do not have to be rebuilt
from scratch. It is useful to be able to record the state of a WMS client application at a
view of interest to a user, and then to restore that state at a later time.
3.3.5 Coverage Portrayal
The Coverage Portrayal Service (CPS) (a discussion paper, not yet an adopted OpenGIS
Specification) enables users to produce visual pictures from coverage data (such as digital
elevation data or Earth image data). The CPS works much like a WMS instance, but
includes additional parameters to control the retrieval and/or rendering of coverage data.
3.4 Catalogue Services
Catalog Services provide a common mechanism to classify, register, describe, search,
maintain and access information about resources available on a network. Resources are
network addressable instances of typed data or services. Types of registries are
differentiated by their role such as registries for cataloging data types (e.g., types of
geographic features, coverages, sensors, and symbols), online data instances (e.g., datasets,
repositories, and symbol libraries), service types and online service instances. Catalog
services allow:
1) Providers of resources to publish descriptive information about resource types and
instances;
2) Requestors of resources to discover information about resource types and instances;
and
3) Requestors of resources to access (bind to) resource providers.
7 https://portal.opengeospatial.org/files/?artifact_id=3841
13 © OGC 2004 – All rights reserved
Catalogue services support the ability to publish and search collections of descriptive
information (metadata) for data, services, and related information objects. Metadata in
catalogues represent resource characteristics that can be queried and presented for
evaluation and further processing by both humans and software. Catalogue services are
required to support the discovery and binding to registered information resources within an
information community.
The OpenGIS
®
catalog document specifies the interfaces, bindings, and a framework for
defining application profiles required to publish and access digital catalogues of metadata
for geospatial content, services, and related resource information. Metadata act as
generalized properties that can be queried and returned through catalogue services for
resource evaluation and, in many cases, invocation or retrieval of the referenced resource.
Catalogue services support the use of one of several identified query languages to find and
return results using well-known content models (metadata schemas) and encodings. This
OpenGIS®
document is applicable to the implementation of interfaces on catalogues of a
variety of information resources.
3.5 Data Services
Data Services provide access to collections of content in repositories and databases.
Resources accessible by Data Services can generally be referenced by a name (identity,
address, etc). Given a name, Data Services can then find the resource. Data Services
usually maintain indexes to help speed up the process of finding items by name or by other
attributes of the item. The OpenGIS Framework defines common encodings and interfaces
in which multiple, distributed Data Services are accessed and their contents “exposed” in a
consistent manner to other major components. The sections below describe the current set
of Data Services of the OpenGIS Framework.
3.5.1 Feature Services
The OpenGIS Web Feature Service Specification8 (WFS) supports the query and discovery
of geographic features and attributes. In a typical Web-base scenario, WFS delivers
Geography Markup Language9 (GML) representations of simple geospatial features in
response to queries from HTTP clients. Clients (service requestors) access geographic
feature data through a WFS by submitting a request for just those features that are needed
for an application. The client generates a request posts it to a WFS instance (a WFS server
on the Web). The WFS instance executes the request, returning the results to the client as
GML. A GML-enabled client can manipulate or operate on the returned features.
3.5.2 Symbology Management
This service is a multi-component system that enables map and content retrieval, and
includes the capability for creating, storing, and/or retrieving styles and symbols from
multiple communities or user groups and combining all these elements of information into
OGC 2004 – All rights reserved
8 https://portal.opengeospatial.org/files/?artifact_id=7176
9 https://portal.opengeospatial.org/files/?artifact_id=7174
14 ©
an appropriately symbolized map. This service may consist of multiple components
including a Style Registry, Style Repository, Symbol Registry, and Symbol Repository
presented through a common, standard interface.
3.5.3 Gazetteer
A Gazetteer is a directory of features containing some information regarding position. A
Gazetteer Service is a network-accessible service that retrieves one or more features (after
the ISO feature model), given a query (filter) request. This filter request must support
selection by well-known feature attribute values, and especially by published or contextunique
identifiers.. The queryable feature attributes are any properties that describe the
features, including but not limited to feature type, feature name, authority, or identification
code. Each instance of a Gazetteer Service has an associated vocabulary of identifiers.
Thus, a Gazetteer Service may apply to a given region, such as a country, or some other
specialized grouping of features. The returned features will include one or more geometries
expressed in an OGC Spatial Reference System. This Gazetteer interface extends the WFS
specification by defining additional behavior and formalizing the response schema
elements. The Gazetteer is service is described in the OGC discussion paper “Gazetteer
Service Profile of a WFS10”.
3.5.4 Coverage Services
The OpenGIS Web Coverage Service Specification11 (WCS) supports the networked
interchange of geospatial content as "coverages" containing values or properties of
geographic locations. Unlike the Web Map Service, which filters and portrays spatial
content to return static maps (server-rendered as pictures), the Web Coverage Service
provides access to intact (unrendered) geospatial information, as needed for client-side
rendering, multi-valued coverages, and input into scientific models and other clients
beyond simple viewers.
3.6 Procurement Issues
The Geospatial Portal Reference Architecture represents a big step forward for
procurement officials seeking to satisfy their agencies' spatial information requirements at
the lowest possible cost, and with the greatest adherence to laws and policies regarding
standards and interoperability.
A portal based on interoperable components using standard interfaces and protocols is
highly flexible and "agile". As requirements or technology change, as market demand
grows, as new functions must be added, a standards based portal can be cost effectively
and quickly enhanced. As new standards and specifications are approved in OGC and
implemented in products, new services and content sources can be effectively integrated
into the Portal infrastructure.
OGC 2004 – All rights reserved
10 https://portal.opengeospatial.org/files/?artifact_id=7175
11 https://portal.opengeospatial.org/files/?artifact_id=3837
15 ©
Existing content producers can usually extend their systems with open interfaces to become
part of geospatial information networks with open portals. Most providers of GIS, Earth
imaging, facilities management, automated mapping, decision support, navigation and
location based services software are implementing these open interfaces on their servers
and clients. Agencies employing the component-based Geospatial Portal Reference
Architecture reduce their risk of "vendor lock in," save money through a buy-as-you-go
approach, and maximize their compatibility with other resources in their networks.
Rapid build-out of the Global Spatial Data Infrastructure (GSDI) depends on agencies
purchasing products with interfaces that implement OpenGIS Specifications. You can't
have a network if the nodes don't interoperate. If they interoperate, it doesn't matter which
vendor provided the software – You can pick the best and/or least expensive. Different
vendors have different strengths and different users have different needs, which is why
agency-wide single vendor mandates seldom hold up over time.
OGC programs reduce technology risk by providing an alternative to "putting all your eggs
in one basket". When the market offers a new component that is better than a similar
component being used by an old component, the old component can be quickly and
inexpensively replaced. Such upgrades are much smaller and more future-compatible when
a non-proprietary framework connects the parts. Governments are seeking procurement
reform. By participating in OGC programs, agencies enhance the market's ability to meet
future procurement needs with standards-based solutions. Two or ten or twenty competing
vendors produce far more options than one vendor contracted to incrementally enhance its
own proprietary systems. All Spatial Data Infrastructure initiatives worldwide are moving
rapidly and inexorably toward interoperability based on open standards, not
interoperability based on one vendor's proprietary architecture.
Governments seeking procurement reform establish policies to support information
technology standards, including standards for interconnectivity and interoperability.
Interconnectivity and interoperability depend on vendor-neutral standards such as TCP/IP,
HTML, SQL and XML. To achieve interoperability in GIS, agencies need to purchase
software with interoperability interfaces that implement the vendor-neutral OpenGIS®
Specifications coming from the Open Geospatial Consortium (OGC). Most of these
specifications get put on track to become ISO/TC 211 standards, and they are endorsed by
the Federal Geographic Data Committee and by a growing number of spatial data agencies
in other countries. OGC is working in a joint coordination effort with ISO TC/211
(Geomatics) as to ensure that market-derived approaches mesh with the global de jure
standards program. This is important for agencies because they need assurance that their
strategies to modernize and stay efficient will be durable and part of the mainstream of
technology development.
16 © OGC 2004 – All rights reserved
4 Summary
The standards-based, vendor-neutral Geospatial Portal Reference Architecture
Describes how to build standards-based portals for easy publishing and use of geodata
and services,
Shows procurement officials how to acquire geoprocessing software that "plugs and
plays" in government enterprise information systems,
Makes it easy to add geospatial capabilities to otherwise non-spatial federal, state and
local E-Government portals, and portals belonging to businesses, organizations and
communities,
Shows how existing GIS's and other geoprocessing systems can be made interoperable
through implementation of OpenGIS standards.
The Geospatial Portal Reference Architecture is a major step forward for E-Government,
National Spatial Data Infrastructures, enterprises and Information Communities. It is made
possible by recent advances in industry consensus on geoprocessing interoperability
interfaces that make it possible to network heterogeneous geographic information systems
and systems for digital cartography, facilities management, Earth imaging, navigation and
location based services. Prior to this time, diverse proprietary data formats and processing
approaches made it very difficult to share digital geospatial content. Now geospatial
content is part of what can be accessed and used on the Web. The Web – and government
enterprise information systems – have been spatially enabled. The Geospatial Portal
Reference Architecture represents the most recent step, and a very important step, in this
extremely valuable progress.
17 © OGC 2004 – All rights reserved