[FrontPage] [TitleIndex] [WordIndex

CSW Development

concepts and development for deegree3 catalogueService

1. Terminology

1.1. Profiles in focus

CSW 2.0.0/2.0.1

CSW 2.0.2







2. Implementationstatus




Description and Report


display the capabilities of the CSW

implemented - (100%)



display the XSD from the requested record

implemented - (90%)

the XSD files are requested remote from the respective sites



not implemented - (0%)



display all the requested records due to the filter expression

implemented - (80%)

there are some minor attributes left which are ignored at the moment because of non-mandatoryness in spec


display the record(s) due to the identifier property

implemented - (90%)

there is an own method implemented that doesn't use the generation of the SELECT statement which is used from the GetRecords-operation

Transaction-operation DC


implemented - (100%)
implemented - (100%)
implemented - (70%)

if you update a complete record there is no problem and is implemented correctly. If you update just some of the mono-properties like the language there is no problem at all and is implemented correctly. But if you update some properties that are multiple properties there is a known bug and has to be fixed soon.

Transaction-operation ISO


implemented - (100%)
implemented - (100%)
implemented - (70%)

same problem as above



not implemented - (0%)



queryable properties

implemented - (NAN)

correctly implemented for inofficial compliance tests


INSPIRE constraints regarding to ISO spec (page 10-11 in INSPIRE spec)
implementing a SWITCH

implemented - (5%)

This switch should touch the properties mentioned at page 10-11 in INSPIRE spec like: language -> mandatory or hierarchieLevel -> mandatory

3. Handling of metadata formats (profiles)

3.1. TypeName / outputSchema

4. Reading relevant Catalogue Specs

4.1. Information model

Provides a formal structure for describing the information resources a catalogue manages to fulfil an application profile.

Mandatory operations

Optional operations

4.2. application profile

A set of international metadata-standards like ISO 19115 or Dublin Core. Application profiles may modify and redefine the realization of the core queryable properties and how their values are encoded.

4.3. information resources

Entities that are managed by a service. Are defined by the information model.

4.4. core queryable properties

Properties on which a catalogue can formulate filter expressions. The goal is:


The INSPIRE document for CSW is a top part specification on the ISO specifications 19115 and 19119. The last version of this specification is used, with title: "INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119". This document can be found at the specific inspire homepage.
Relevant information is on page 10 and 11 which constraints the ISO metadata set. There is a switch implemented already to change between a INSPIRE conform- or non-conform CSW. This implementation has to be improved to be conform regarding to the points specified at page 10 and 11 in INSPIRE spec.

5. General CSW interface model

5.1. discovery class

It provides 4 operations for client-discovery:

5.2. session class

It provides 4 operations for interactive sessions between client and server:

5.3. manager class

It provides 2 operations for interacting with the cataloguestore (push) und retrieving metadata from other services (pull)

5.4. brokered access class

It provides the order operation.

6. Architecture




The CSWController delegates a request either to a DC or ISO recordstore. If a describeRecord operation has to be managed there should be a mapping from the typeName to the relevant store. Question is: how to map, just to DC if typeName is DC or to ISO al well?

7.1. DummyDatasets (closed)

7.2. BoundingBox

8. Multilinguarity

The INSPIRE-specification defines the multilinuarity for the CSW.

9. Implementation

10. GetCapabilities

10.1. getRecords

Difference between a CodeList and Enumeration is not so clear...so have taken Enumeration -> like resultType: Spec says to take a CodeList, but in the Code taht is as Enum implemented. The same is true for CONSTRAINTLANGUAGE, by the way.

10.1.1. Parsing startPosition

Is there any usecase? just for info... outputFormat ElementName/ElementSetName

the examples are taken from the spec page 149 to summarize it in this doc:

<csw:Query typeNames="rim:ExtrinsicObject rim:Association">

(if taken the DC profile) this code can be abbreviated into:

<csw:Query typeNames="csw:Record">

=>ElementName and ElementSetName are mutually exclusive! Either an ElementSetName OR 1..* ElementName shall be specified in a query [thinking there is a fault in the Spec page 151]

10.1.2. DB-Access/Output Structure

For handling the parsed request, there has to be implemented a transformation from the request (KVP/XML) to an SQL statement. At the moment there is a PostGres database maintainting the data. So this has to be an abstraction layer, because the maintaining can be managed by other database provider. In the Core-implementation of the RecordAPI there is a package for transforming the request into PostGreSQL.

To handle the various geometries, there is a WKTReader/WKBReader and ~Writer derived from the JTS implemented. Because of the complexity of the geometrymodel of deegree this is popular for the simple features but has to be expanded for the other geometries in deegree -> thinking of encapsuling from JTS completely.


2018-04-20 12:04