Add metadata to CoverageSummary in GetCapabilites response.

[jpass@…]

It is not yet possible to add any metadata for a coverage in the WCS GetCapabilities response.

Metadata should be located at:

/wcs:Capabilities/wcs:Contents/wcs:CoverageSummary/ows:Metadata

[abeccati]

Looks like it can be handled like the gmlcov:metadata served with a describeCoverage response so uses can load it as a text string associated to the coverage. I tentatively fit this into 8.4.

[Dimitar Misev]

This could potentially lead to a huge Capabilities document, is it really necessary there?

[jpass@…]

Yes please. This follows the pattern of other WxS GetCapabilities responses. We just need the ability to specify a URL to the associated coverage discovery metadata. Something like:

<MetadataURL type="TC211">
<Format>
application/xml; charset=UTF-8
</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://metadata.bgs.ac.uk/geonetwork/srv/en/csw?service=CSW&request=GetRecordById&elementSetName=full&OutputSchema=http://www.isotc211.org/2005/gmd&ID=9df8df52-d609-37a8-e044-0003ba9b0d98&"/>
</MetadataURL>

[Dimitar Misev]

Ah ok, so it's not about including the whole metadata but just a link. I suppose there's no way for petascope to generate this link automatically.

And you'll have the same metadata in the DescribeCoverage right?

Is it that some client tool expects this metadata info in the Capabilities and can't get it from the DescribeCoverage (just one more level of indirection? I'm just curious why can't the DescribeCoverage be used.

[jpass@…]

I'm not sure we will have the same metadata in the DescribeCoverage

[Dimitar Misev]

Ok, these kind of details are important because it means we'll have to change the database schema so that different metadata can be stored for the Capabilities document.

[Piero Campalani]

This feature could be easily enabled in Petascope now, the new database can already store OWS extrametadata in ps9_extra_metadata, referencing the type ows in ps9_extra_metadata_type. See also import_mr() function in rasdaman/systemtest/util/petascope.sh:

# add GMLCOV and OWS extra metadata                                                                                                                                     
GMLCOV=gmlcov
OWS=ows
$PSQL -c "INSERT INTO ps9_extra_metadata (coverage_id, metadata_type_id, value) VALUES (\
            $c_id, (SELECT id FROM ps9_extra_metadata_type WHERE type='$OWS'),\
            'test ows metadata');" > /dev/null || exit $RC_ERROR
$PSQL -c "INSERT INTO ps9_extra_metadata (coverage_id, metadata_type_id, value) VALUES (\
            $c_id, (SELECT id FROM ps9_extra_metadata_type WHERE type='$GMLCOV'),\
            'test gmlcov metadata');" > /dev/null || exit $RC_ERROR

So, petascope.wcs2.handlers.GetCapabilitiesHandler could read them, as it is done for gmlcov now in petascope.util.WcsUtil:

// GMLCOV metadata
Set<String> gmlcovMetadata = m.getMetadata().getExtraMetadata(XMLSymbols.PREFIX_GMLCOV);
String gmlcovFormattedMetadata = "";
for (String metadataValue : gmlcovMetadata) {
    gmlcovFormattedMetadata += "<" + XMLSymbols.PREFIX_GMLCOV + ":" + 
        XMLSymbols.LABEL_METADATA + ">" + metadataValue + "</" + XMLSymbols.PREFIX_GMLCOV +
        ":" + XMLSymbols.LABEL_METADATA + ">";
}

The fact that CoverageSummary metadata should be enabled however is not yet solved.
For participating in this, you can reply to:

​https://groups.google.com/d/msg/rasdaman-users/lSMM3i4bdhQ/nxSf3PhCCG8J

[Piero Campalani]

Note: OWS metadata is stored in the db as a simple string, hence the full XML element shall be stored in the database so that the db does not have to handle mandatory/optional attributes etc.

[Peter Baumann]

if we store this as a text string this will not be searchable anyway (if the text string is XML we have no XQuery facility availble yet, and even cannot check whether it is well-formed XML, as metadata can be <any>thing).
PML wanted only a link stored. While this is small, there are use cases where metadata are whole coverages again, pr polygon sets, etc - so: big and complex. Makes GetCapabilities impossible to handle, a real blocker.
Note that OWS Common has most elements optional, so it is up to a service to decide whether to include them or not, there is no obligation.
Therefore, why not say: we support metadata up to 1000 chars, and deliver them.
In the future, when we have a schema-based metadata modeling (will we at some time?) we can do more.

[Piero Campalani]

Yes, we are far from a comprehensive handling of OWS metadata: tons of optional attributes are proposed there.

​http://www.schemacentral.com/sc/niem20/t-ows_MetadataType.html

Replying to pbaumann:

Therefore, why not say: we support metadata up to 1000 chars, and deliver them.

Do you mean we can add a trigger on INSERT/UPDATE of coverage extra-metadata to check that length is < 1000 chars if OWS metadata type is selected?

[Piero Campalani]

ows:Metadata

[Piero Campalani]

OWS metadata enabled in changeset:9675bff.

A new parameter 'enable_ows_metadata' in petascope.properties has been added to let Petascope ignore the OWS metadata, in case.

Updated guidance is provided in the user guide.

(James, please let me know when you can test the feature)

[abeccati]

Milestone 9.0-beta1 deleted

[Dimitar Misev]

We should close this right, patch is in the repo?

[Piero Campalani]

Closing the ticket with explicit request from the reporter (he seems he does not have the rights to edit the ticket anymore).