The Way to Open Geospatial Services
Are you interested in SDI interoperability? Do you want to support open access to geospatial services? Is your interest to make existing OGC services more accessible?
We would like to support voluntary SDI initiatives by our catalogue service SuperCat. Try the new global geospatial catalogue at:
or integrate our CSW into your portal:
Register your CSW in SuperCat.
Please find some instructions in the following videos.
After registration, your services will become publicly available within 24 hours.
The Idea of SuperCAT
There are many OGC web services available worldwide which may be widely used in different applications. In order to make SDI or other application operable, it is crucial to have the services available and reliable at any time.
In real life, many problems occur with regard to operability and access to services. Several examples can be mentioned:
- Not all services have public metadata record that can be used for searching the services. The services are not catalogued.
- Services are usually registered in catalogues and it is to discover them (e.g. OGC CSW, geoportals). However, the services cannot be simply searched by common search engines like Google or Bing. The services can be then searched only through the catalogues they are registered in or using the web address of the service.
- In many cases, metadata records are not up-to-date and links to services are not valid or not provided at all. Sometimes, the provided URL links to a web page or a viewer rather than to the service connect point.
- Some catalogues don't respond. The same problem occurs with other services.
- Service metadata can be catalogued differently. There are no common "global" rules how to uniquely code some element, e.g. serviceType. The query may not provide results without any errors.
Catalogue Interoperability Problems
An analysis of several catalogues was performed. The following problems were detected:
- The catalogue is not functioning. The catalogue was either moved to another address, is temporarily unavailable or password protected.
- The catalogue is not properly implemented according to the CSW 2.0.2 specification (older version, errors, etc.) or it is based on another standard.
- Many aspects in the current version of the CSW 2.0.2 specification are unclear or missing. As a result, service vendors implement them in different way (e.g. harvesting of catalogues, behavior of different typenames, queryables).
- CSW should support Dublin Core (csw:Record) and other profiles are optional. There are implementations of ebRIM, ISO, FGDC and others. For INSPIRE the ISO AP 1.0 standard is mandatory. However, not all catalogues support it.
- CSW should support GET, POST and optionally SOAP protocol. In most implementations, POST and SOAP are not used. Not all catalogues implement these protocols for the GetRecord and GetRecordById operations.
- Query languages. CQL and OGC Filter should be supported. Some catalogues has errors in implementation or does not support full language properties.
- There is a mandatory set of queryables. INSPIRE requires additional ones which are usually not implemented by service vendors.
Central Catalogue Implementation and Testing
In order to provide users easy access to services that are correctly implemented, a service metadata repository was built on our server. The repository:
- is CSW 2.0.2 ISO AP 1.0 compliant;
- supports the INSPIRE metadata profile and queryables;
- enables to register remote catalogues and harvest them periodically (Figure 1);
- enables to harvest other services (WMS, WFS, WCS, CSW) and individual metadata files;
- enables verification of registered services (Figure 2 and 3).
The service metadata repository was tested using the following set of metadata catalogues:
- INSPIRE national catalogues: Austria, Belgium, Czech Republic, Finland, France, Germany, Luxembourg, Poland, Portugal, Slovakia, United Kingdom
- EEA SDI
- One Geology Europe
These resources are daily harvested and services are filtered (type=service). A harvesting protocol from is generated for checking the availability of the catalogues. Mail notifications are sent to corresponding users to ensure feedback.
The test of service availability is performed on daily basis for all services (only WMS at this phase). If a service is not running, the corresponding metadata record is not deleted but only hidden. This can ensure that temporarily unavailable services can be tested in the future.
Figure 1 – SuperCat harvesting configuration.
Figure 2 – RSS channel – harvesting results.
Figure 3 – Heartbeat protocol.
2222 services were harvested from the registered catalogues. WMS services were analysed in detail. See the results in Table 1). 87% of all the services were responding.
|Service type code||Number||Responding (number)||Responding (%)|
The following problems were identified while testing:
- serviceType is in many cases ambiguous (see service type codes in Table 1). The INSPIRE Directive brings more confusion into service classification.
- There is no thematic classification for services and metadata are of poor quality. As a result, catalogue queries are not efficient. At least INSPIRE theme keywords or other commonly used code list would be good step to introduce thematic classification.
- Unique service URL is not stated. INSPIRE says, it would be Capabilities document URL (e.g. distributionInfo/*/transferOptions/*/onLine/*/linkage= http://<my-service>?service=CSW&REQUEST=GetCapabilities), but it is coded different way. Only service connect point in most cases and additionally distributionInfo/*/transferOptions/*/onLine/*/protocol=OGC:WMS-1.1.1-http-get-capabilities, but it varies from service to service).
The central catalogue enables smooth access to dozens of services on one portal (Figure 4).
Figure 4 – portal – metadata catalogue client.
A mobile solution for simple access to an SDI was developed and tested (Figure 5).
Figure 5 – Mobile application.
Plans for the Future
- More detailed services checking (currently only capabilities documents are tested).
- More catalogues and services will be harvested.
- WFS, WCS, KML, WPS and SOS metadata will be processed.
- A web interface that can be searched by commonly used search engines (e.g. Google) will be developed.