Opened 4 years ago

Closed 21 months ago

#439 closed defect (fixed)

usage of ps_descriptions table in petascope 8.x

Reported by: damiano Owned by: bthapaliya
Priority: critical Milestone: Future
Component: petascope Version: 8.5
Keywords: ps_descriptions Cc: mantovani@…, dmisev, pcampalani, pbaumann
Complexity: Easy

Description

in table ps_descriptions "abstract" and "keywords" are not used

Change History (25)

comment:1 Changed 4 years ago by damiano

  • Summary changed from ps_descriptions table in petascope 8.x to usage of ps_descriptions table in petascope 8.x

comment:2 Changed 4 years ago by abeccati

  • Cc dmisev pcampalani added
  • Complexity changed from Medium to Easy

Thanks for reporting Damiano.

From a quick look at WCS 2.0 and GMLCOV 1.0.1 specs I could not find reference to "keywords" hence I think this belongs to some other related standards, would you please provide where you expect these fields to be outputted to make this report self-contained so we can speed up its resolution by a community member?

Once this info is there I think the ticket can be considered "easy" to solve = good for newcomers.

comment:3 Changed 4 years ago by pcampalani

I also searched through the schemas some time ago, and found no keywords to be associated to coverages.
They can however be set in the service capabilities by overwriting/editing the template in Petascope (petascope.wcs2.templates.ServiceIdentification.templ, eg with Tomcat in $CATALINA_BASE/webapps/petascope/WEB-INF/classes/petascope/wcs2/templates/). See also PetascopeUserGuide#Servicecapabilitiesmetadata .

However the table ps_description suggests these are per coverage.
Looking into the code I see these fields are only used in the updateMetadataWithDescription method in the wcst package:

$ grep updateMetadataWithDescription [...]/java/petascope/ -R
java/petascope/wcst/transaction/executeTransaction.java:    private CoverageMetadata updateMetadataWithDescription(CoverageMetadata meta, CoverageDescriptionType desc) throws WCPSException, WCSTException {
...

comment:4 Changed 4 years ago by pcampalani

Corrige: description elements are possible in a CoverageSummary, however Petascope is not using them.
If you need them I suggest to participate in this discussion at some point.

comment:5 Changed 3 years ago by pcampalani

  • Keywords ps_descriptions added
  • Milestone set to Future

comment:6 Changed 3 years ago by pcampalani

  • Owner changed from abeccati to pcampalani
  • Status changed from new to accepted

They are actually allowed in the general ows:DescriptionType, which is extended by the wcs:CoverageDescriptionType.
http://schemas.opengis.net/ows/2.0/owsDataIdentification.xsd

comment:7 Changed 3 years ago by pcampalani

Patch is submitted.

Once accepted the content of the table ps_descriptions will not be ignored, and will fill in the correspondent OWS elements in the coverage descriptions.
One raw per coverage is admitted by database contraints, and I saw in the WCS 1.0.0 implementation that for keyword it was allowed a syntax to permit multiple keywords, see:

petascope.wcs.server.core.executeDescribeCoverage class which uses the str2String() method of the SDU class in the package petascope.wcps.server.core for the keywords:

...
if (string.startsWith("{") && string.contains(",") && string.endsWith("}")) {
...

This means that:

# SELECT * from ps_descriptions;
 id | coverage |    title     |    abstract     |    keywords     
----+----------+--------------+-----------------+-----------------
  1 |        1 | this title 1 | this abstract 1 | this keyword 1
(1 row)

will resolve to:

<wcs:CoverageDescription ...>
  <ows:Title>this title 1</ows:Title>
  <ows:Abstract>this abstract 1</ows:Abstract>
  <ows:Keywords>this keyword 1</ows:Keywords>
...

And this:

# SELECT * from ps_descriptions;
 id | coverage |    title     |    abstract     |     keywords     
----+----------+--------------+-----------------+------------------
  1 |        1 | this title 1 | this abstract 1 | {key1,key2,key3}
(1 row)

will resolve to :

<wcs:CoverageDescription ...>
  <ows:Title>this title 1</ows:Title>
  <ows:Abstract>this abstract 1</ows:Abstract>
  <ows:Keywords>key1</ows:Keywords>
  <ows:Keywords>key2</ows:Keywords>
  <ows:Keywords>key3</ows:Keywords>

If the same behavior is needed for multiple titles and abstracts, please just request it.

comment:8 Changed 3 years ago by pcampalani

Fixed in changeset:b277588.

comment:9 Changed 3 years ago by pcampalani

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:10 Changed 3 years ago by pcampalani

  • Priority changed from major to critical
  • Resolution fixed deleted
  • Status changed from closed to reopened

An important leak in the submitted patch breaks the WCS service when non mandatory fields like abstract and keywords are left blank.

Current Workaround: set those fields as empty strings, rather then letting them null.

comment:11 Changed 3 years ago by dmisev

Not sure which version does that patch affect (as milestone is Future)?

comment:12 Changed 3 years ago by pcampalani

  • Status changed from reopened to accepted

comment:13 Changed 3 years ago by pcampalani

This is on release_8.5 branch, and the leak occurs from v8.5.2 on. Patch upcoming.

comment:14 Changed 3 years ago by pcampalani

What I said in comment:6 is wrong: wcs:CoverageDescriptionType does not extend ows:DescriptionType, but rather gml:AbstractFeature which does not include an ows:DescriptionType` element (the one for titles, abstracts and keywords).

This means that now the addition of title (+ abstracts or keywords) breaks the validity of the GML response.

This fragment:

  <ows:Title>this title 1</ows:Title>
  <ows:Abstract>this abstract 1</ows:Abstract>
  <ows:Keywords>key1</ows:Keywords>
  <ows:Keywords>key2</ows:Keywords>
  <ows:Keywords>key3</ows:Keywords>

taken from ps_descriptions should go in the coverage summaries of a GetCapabilities response.

In order to have a valid GML, currently it is better to drop the contents of ps_description.

comment:15 Changed 3 years ago by pcampalani

  • Cc pbaumann added

Being the capabilities document always quite a hot topic, I will address the two issues in two different patches: one for the null pointer (ready for subhmission) and the second for moving those elements to the capabilities document (after discussion).

comment:16 Changed 3 years ago by pcampalani

Null pointer error fixed in changeset:0e4b2e5.

comment:17 Changed 3 years ago by mantovani

Having discussed with endusers, we need to move from DescribeCoverage? to GetCapabilities? this:
<ows:Title>this title 1</ows:Title>

<ows:Abstract>this abstract 1</ows:Abstract>
<ows:Keywords>key1</ows:Keywords>
<ows:Keywords>key2</ows:Keywords>
<ows:Keywords>key3</ows:Keywords>

comment:18 Changed 3 years ago by pcampalani

This could be easily done, and should be done since we have this feature available.

From #314, we have now a parameter for enable/disable the OWS Metadata element in a capabilities document, we could change its purpose to switch for light/fat capabilities: light capabilities drops out OWS metadata and coverage descriptions (title/abstract/keywords).

comment:19 Changed 3 years ago by mantovani

No objections from my side for this solution:

  • light mode provides faster performance
  • fat mode provides slower performance with detailed information

comment:20 Changed 3 years ago by mantovani

any decision / step forward on this ticket?

comment:21 Changed 3 years ago by pcampalani

It seems that configuration in petascope.properties is the way to go (see #735 also).
I'll patch the new params soon. !

comment:22 Changed 3 years ago by pcampalani

  • Resolution set to fixed
  • Status changed from accepted to closed

(Configurable) coverage descriptions added to coverage summary in changeset:46aaa33.
An update of petascopedb is needed.

The patch is related to v9, not to v8.5 as this ticket, so I spawned #802 for it.

comment:23 Changed 3 years ago by pcampalani

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:24 Changed 3 years ago by pcampalani

  • Owner changed from pcampalani to bthapaliya
  • Status changed from reopened to assigned

comment:25 Changed 21 months ago by dmisev

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in 9+, I don't think we'll do it in v8 though, so closing.

Note: See TracTickets for help on using tickets.