OGC Catalog Service for the Web
(CS/W): experience in NASA
John D. Evans, Ph.D.
john.evans@nasa.gov
NASA Geosciences Interoperability Office (GIO)
Earth Science Applications Division
-/- Global Science & Technology, Inc.
Goddard Space Flight Center, Greenbelt, MD
Introduction & overview
●
OGC CS/W specification: Spring 2004
–
(After many iterations)
●
OGC ebRIM profile: Fall 2005
●
NASA experimenting with CS/W since Fall 2004
●
Two implementations in particular:
●
–
ECHO CS/W connector (Center for Spatial Information
Science & Systems [CSISS], George Mason University)
–
Earth Science Gateway (NASA Geosciences Interoperability
Office [GIO] & Compusult Ltd.)
Implementation experience
–
Insights, opportunities, and challenges
GMU / CSISS experience with CS/W
●
Bird’s eye view
- From Bai, Y., et al., 2007: Towards a Geospatial Catalogue
Federation Service, Photogrammetric Engineering & Remote
Sensing 73 (6), pp. 699-708
GMU / CSISS experience with CS/W
●
Inside the Catalogue Federation Service
- From Bai, Y., et al., 2007: Towards a Geospatial Catalogue
Federation Service, Photogrammetric Engineering & Remote
Sensing 73 (6), pp. 699-708
GMU / CSISS experience with CS/W
●
●
ebRIM model extends OGC CSW
for geospatial resources
ebRIM + OGC Catalogue Service for CS/W + OGC
Catalogue Service for ISO 19115/19119
RegistryObject
ClassificationSchema
Service
Service Info. Model (ISO 19119)
Classification
ExtrinsicObject
Association
ServiceBindings
……
CSWExtrinsicObject
RepositoryItem
RegistryEntry
Dataset Info. Model (ISO 19115)
NASA EOS Core System (ECS)
Slot
GMU / CSISS: CS/W bridge to ECHO
●
http://laits.gmu.edu:8099/ECHO9CSW2/discovery
●
Connects to the full, operational ECHO
●
●
●
Partial ECHO–ebRIM mapping. Emphasis:
–
CS/W core queryables (Dublin Core)
–
Granules (not Collections)
Performance issues:
–
ECHO not fully optimized for granule-level search
–
ECHO 8 responds to most queries from CS/W connector in
under 2 minutes (used to be worse)
–
ECHO 9 may further improve query performance
Multiplicity of schemas poses add’l challenges
–
CS/W used as a “hub” for several different catalogs
NASA / GIO Earth Science Gateway (ESG)
Earth Science Gateway (ESG)
Service Manager
OGC CSW Requests
- GetCapabilities (1)
- GetRecords (2)
Web
Publishing
Client
OGC CSW Transactions (3)
- Insert
- Update
- Delete
OGC
WFS
Servers
OGC Repository Extensions
- GetRepositoryItem (4)
- PutRepositoryItem (5)
OGC
WCS
Servers
Capabilities XML
Document (1)
External
Applications/Clients
Search
Results (2)
Transaction
Status (3)
OGC
WMS
Servers
Service
Manager
Repository
Item (4)
Repository
Status (3)
Service Registry
Database (Oracle)
Earth Science Gateway (ESG)
Service Manager
●
ESG portal uses CS/W internally for allWeb
Publishing
catalog access
Client
OGC CSW Requests
- GetCapabilities (1)
- GetRecords (2)
–
Search
–
Publish
–
Harvest
OGC
WMS
Servers
OGC CSW Transactions (3)
- Insert
- Update
- Delete
OGC
WFS
Servers
OGC Repository Extensions
- GetRepositoryItem (4)
- PutRepositoryItem (5)
●
Capabilities XML
Public interface available
for other CS/W clients
Document (1)
●
Search query other CS/W servers
Simple
HTML client can
External
Applications/Clients
Results (2)
Transaction
Status (3)
OGC
WCS
Servers
Service
Manager
Repository
Item (4)
Repository
Status (3)
Service Registry
Database (Oracle)
ESG in OGC Web Services Testbed 3
●
●
●
Successful connections from a Refractions
Research CS/W client (Nov. 2005)
Key challenge: reconciling different ebRIM
representations
–
E.g., WMS Layer Extrinsic Object: is its ObjectType “Layer”?
“WMS_Layer”? or “Data_Set”?
–
A guessing game; create equivalencies to fit queries coming
from different clients
–
Changing an ebRIM type name can be a headache
Another challenge: maintaining performance
–
Query response slowed a lot at 100k-200k records.
–
Server-side workarounds: temp tables; caching; returning
summaries rather than full records
ESG in OGC Web Services Testbed 4
EO-1
UAV
ESG: ebRIM model of OGC Web Service
Service
Binding
Service Binding
User
Classification
Classification
uuid =
service
OffersService
uuid =
classified_object
Service
HasFootprint
ExtrinsicObject
ExtrinsicObject
(WMS, WFS, WCS)
ExtrinsicObject
Offers
objectType =
Geometry
uuid =
parent
HasFootprint
objectType =
Context Document
(WMS only)
Layer
Layer/ /featureType
featureType/ /
CoverageOfferingBrief
CoverageOfferingBrief
HasContext
ExtrinsicObject
Extents
objectType
objectType==
Describes ExtrinsicObject
objectType =
Dataset Description
(Metadata Document)
uuid =
classified_object
Classification
ESG: ebRIM model of OGC Web Service objects
(WMS Layer, WFS FeatureType, WCS CoverageOffering)
ExtrinsicOject
ExtrinsicOject
objectType
objectType
=
= LayerStyle
LayerStyle
Service
HasLegend
ExtrinsicOject
ExtrinsicOject
objectType
objectType
= Legend
= Legend
(WMS, WFS, WCS)
Offers
Externally
Links
ExternalLink
ExternalLink
Extents
Extents
Styles
Classification
Classification
ExtrinsicObject
objectType = Layer, or
featureType, or
CoverageOfferingBrief
uuid =
classified_object
Describes
g.uuid =
e.parent
HasFootprint
ExtrinsicObject
objectType = Geometry
ExtrinsicObject
objectType =
Dataset Description
(Metadata Document)
HasFootprint
ESG and CS/W interoperability
●
●
ESG as CS/W server:
–
http://esg.gsfc.nasa.gov/wes/serviceManagerCSW/csw
–
Successful CS/W connections from
Intergraph testbed client
–
Prototype CS/W connections from European Space Agency
(ESA) client [http://eoportal.org]
ESG as CS/W client:
–
●
Successful CS/W connections to GMU/CSISS ECHO
connector
Differences in ebRIM representations continue to be
the main challenge
–
Conforming to CS/W is necessary but NOT sufficient for
catalog interoperability
CS/W opportunities & challenges
●
●
OGC CS/W interface definition is owned by
no-one (consensus-based)
–
Support by vendors, open source, etc.
–
Used across many different sectors of activity
ebRIM is a promising “common ground” for catalogs
–
Very flexible meta-model
–
Growing momentum in e-business
●
●
Expect tools to manage the complexity
ebRIM: not the answer BUT a good framework for
expressing the answer
CS/W opportunities & challenges
●
●
CS/W & ebRIM complexity / generality
–
Impedes wider implementation
–
Impedes wider consensus on profiles?
Representing earth imagery in ebRIM:
–
●
E.g., ESA’s EO products profile (slow adoption so far)
●
Lots of support for product ordering
●
Little support for service binding
–
No one ebRIM representation will fit everyone
–
Need an imagery counterpart to Dublin Core?
NASA community could enhance catalog
interoperability by defining one or more overlapping
CS/W ebRIM representations