Aus GISpunkt HSR
Wechseln zu: Navigation, Suche

'Catalog Services for the Web' from OGC.

See also OAI-PMH and especially HowTo OAI-PMH for harvesting geo-metadata.

Specifications and software:

  • OGC-CSW 2.0.1, OGC Catalogue Services Specification, version 2.0.1 OGC 04-021r3.
  • GeoNetwork opensource v2.1 (GN) the Reference Implementation of CSW.

The following OGC specifications are also relevant for CSW (!):

  • OpenGIS Web Services Common Specification, version 1.0.0 OGC 05-008c1
  • Filter Encoding Implementation Specification, version 1.1.0 OGC 04-095
  • Geographic information -- Geography Markup Language OGC 03-105r1

CSW servers


CSW is not the only catalog specification from OGC. There is a competing specification called 'ebRIM Profile' (!!!) :-O.

Harvesting is not yet implemented in GeoNetwork (GN) - the reference implementation (!!!). Question from the GeoNetwork-devel mailing list: "Why the CSW harvesting compliant with the OGC spec. is not implemented in GN 2.1". Answer (26.09.2007 14:07): " The CSW harvesting operation has a not well defined sematics and is not flexible enough to allow a good harvesting. The specs are continually changing making its usage useless. I'm finishing to implement the OAI-PMH harvesting protocol and, IMHO, it outperforms CSW harvesting on all aspects.".

The following is from OCG's "Catalogue Service Implementation Specification", 2.0.2 (OGC 07-006r1, chap. 6.3.3) and from http://schemas.opengis.net/csw/2.0.2/examples/:

 <?xml version="1.0" encoding="ISO-8859-1"?>
    xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 ../../../csw/2.0.2/record.xsd">
   <dc:creator>U.S. Geological Survey</dc:creator>
   <dc:contributor>State of Texas</dc:contributor>
   <dc:publisher>U.S. Geological Survey</dc:publisher>
   <dc:subject>Elevation, Hypsography, and Contours</dc:subject>
   <dct:abstract>Elevation data collected for the National Elevation Dataset (NED) based on 30m horizontal and 15m vertical accuracy.</dct:abstract>
   <dc:rights>Copyright © 2004, State of Texas</dc:rights>
   <dc:title>National Elevation Mapping Service for Texas</dc:title>
     <ows:LowerCorner>-108.44 28.229</ows:LowerCorner>
     <ows:UpperCorner>-96.223 34.353</ows:UpperCorner>

That example should be a dataset and not a service. Here is my proposal of a WCS service metadata set which points to the record above:

 <?xml version="1.0" encoding="ISO-8859-1"?>
     <ows:LowerCorner>-108.44 28.229</ows:LowerCorner>
     <ows:UpperCorner>-96.223 34.353</ows:UpperCorner>

How to encode WGS84 Bounding Box?

The example in "Full record" shows element ows:WGS84BoundingBox (instead of ows:BoundingBox) and the text in "Summary Response Record" mentions "dct:spatial" for the encoding. Then, "OGC's Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W (0.1.7)" mentions again dct:spatial !???

Proposal: ows:BoundingBox or dct:spatial (both with CRS=WGS84 as mandatory/default)

How to encode record sets?

csw:Record is a single instance. How to encode record sets??

Proposal: ?

How to encode services?

Services can be divided into WxS being "Data Access Points" to datasets and to services on their own being Processing Services (WPS), like Coordinate Transform, which don't have any specifically related dataset.

In order to not confuse people too much who believe, WMS is a service on its own, and to simplify harvesing of WMS I propose the following:

Dataset record: A record of dc:type=dataset and 
Service record: Another record of dc:type=service with dct:references=<identifier-of-dataset>. 

dct:references is part of the dc:relation subgroup. Here, for example, a WMS URL would be encoded in dc:identifier of the service record.