Discussion of the Download Services Technical Guidance

| Share
Group discussion > The Atom spec puzzles me...

The Atom spec puzzles me...

Paul van Genuchten
1004 days ago

Last years we've seen an increased interest in the Atom format related to the download service specifications. A format that still puzzles me. Personally I don't see clear usecases for this format. Maybe one of you can enlighten me. In GeoNetwork we currently have 2 Atom implementations targetting two different usecases. The oldest implementation offers an opensearch interface on the full catalogue. This search option uses the iso19139 metadata to filter results related to a certain search query and creates an Atom document from iso19139. This is a good use case as it enables users to query geonetwork from the browser search-panel. However this is not the usecase the INSPIRE download specification seems to target. In stead an open search option is proposed within the scope of a single download service. This might be relevant if a download service contains a huge number of datasets. In the implementations I know of download services usually contain only a couple of datasets. The specification on the other hand is focussing on a limited number of datasets, as it lists each of the datasets in the open search description (if the download service contains a milion datasets this document would explode).

Another consideration is the generation of the Atom ducuments. In Geonetwork these documents can be generated from the iso19139 metadata content. However the second implementation doesn't use this functionality. In stead Atom files that are placed in an external location are ingested into the catalogue to facilitate search options on it. The reason for this was based on accountability. The provider of the discovery service doesn't want to be accountable for the contents of the Atom documents, because these are part of the download service, for which this provider is not accountable.

During the implementations we've found some unresolved issues in the specification. In the second implementation it is not specified how a machine can notice which of the online-resources in the iso19115 distribution info section is actually an Atom document containing links to files. This Atom file should be read by the catalogue client to present users a list of available downloadable files, to prevent the user having to click another time to open the atom file. In GeoNetwork we are suggesting to use a protocol Atom/OpenSearch, which is then automatically assumed being an Atom document.

In the first implementation we've found some challenges in the mapping from iso19139 to INSPIRE-Atom. INSPIRE-Atom implements a keyword-reference to the INSPIRE-feature-concepts-dictionary referencing the featuretype-concept that is offered in the Atom. The INSPIRE-iso19139 spec doesn't currently require this keyword. Other challenges are related to the Coordinate system and Filesize attributes which are defined slightly different between iso19139 and INSPIRE-Atom.

I also gave the INSPIRE Atom Client for QGIS a try (https://plugins.qgis.org/plugins/inspireatomclient). But i didn't get it to work on either of the above mentioned Atom implementations. I hope that by discussing here we can improve in this area and come to a general understanding and implementation hints.

Some links:


Ken Bragg
847 days ago

Hi Paul

Interesting discussion, I'm curious if you had any reponses to this post or outside discussion? We see organizations attracted to the ATOM download specification because quite honestly it seems easier to implement than WFS.  But then there is the client question. One could argue that the Atom download links are simple file downloads and in some ways easier to deal with than WFS. Athough on the other hand we aren't aware to many clients ready to read from this ATOM specification. Our product FME can act as a client with some minor workspace configuration (see here) and there is the QGIS plugin you mentioned. Are there area others you aware of?