Coverage metadata overwritten in range constructor

[Piero Campalani]

(Root problem of ticket #741)

When building a coverage through a WCPS range constructor (like for building RGB covs), the info variable (CoverageInfo class) is overwritten by every subsequent range component.

Due to this, problems can arise when the last range component (eg blue band for PNG encodings) has a different metadata profile from other components.

The problem is serious when shortcuts are used to fill in range components with silent scalar to coverage conversion: the scalar metadata profile is kept and becomes the CoverageInfo of the overall coverage.

[Marcus Sen]

It has just struck me that, although using a single scalar is extremely convenient when you just want the same constant value in one component of the range with the same domain as the other components, I'm not absolutely sure whether this behaviour is what the WCPS standard defines. It suggests that all coverages should have the same domain. This would complicate a lot of queries but perhaps this should be discussed with WCPS standards people to check definition and whether standard itself needs changing or rephrasing?

[Dimitar Misev]

According to the standard all fields in the range constructor must be coverages with the same domain and CRS. The scalar components is just a hack we have implemented (although in WCPS 2.0 it will be allowed).

[Peter Baumann]

actually, WCPS does not require that all coverages have the same domain (neither does WCS, BTW). The only requirement in the context of this discussion is that a single coverage has one domain definition (including domain extent and resolution) - regardless of the range type, ie: the number of bands. This is a requirement of GMLCOV.

[Peter Baumann]

that overwriting behavior actually looks ok to me: a coverage has one domain, one coverage info. So all bands input must have the same info anyway, hence we can freely pick, eg, the last one - makes sense to me!

[Dimitar Misev]

In WCPS 1.0 [08-068r1] they have to match, unless I'm missing something:

7.1.22 rangeConstructorExpr

The rangeConstructorExpr, an n-ary induced operation, allows to build coverages with compound range structures. To this end, coverage range field expressions enumerated are combined into one coverage.

All input coverages must match wrt. domains and CRSs. An input coverage range field may be listed more than once.

[Marcus Sen]

Having looked at the current WCPS 1.0 standard I now think that as Dimitar has quoted the expressions we had been using before with a shortcut constant value instead of an explicit coverage in some bands is not strictly conformant to the standard. However, what to do now needs some discussion (possibly on an email list like rasdaman-users to get user input?). If we accept that the expressions using a single scalar in one or more bands are not correct WCPS then really an error should be thrown rather than them working sometimes but tripping you up unexpectedly with consequential errors like this. However, this could break quite a lot of applications I expect as the shortcut notation is very intuitive and convenient. If this is going to be acceptable in WCPS 2.0 that also needs bearing in mind. To workaround the transparency problem in #741 we only need to make sure the last band has a proper domain defined, it will work with some other bands just specified as constant scalars although this wouldn't strictly be correct WCPS. This is confusing. I'm not sure of the best course of action and I'm not sure where discussion of standards changes best takes place (is it on the WCS.SWG list?) but rasdaman-users might get more user input.

[Peter Baumann]

interesting discussion, thanks for the background! Actually, WCPS 1.0 ist not yet strictly streamlined with GMLCOV. WCPS 2 is going for that, and exactly the coverage constructor is causing me headaches. So I'm eager to learn more about the specific situations, the idea of the shortcuts, etc. - maybe it helps us to flesh out how WCPS 2 can do this meaningfully.

[Marcus Sen]

The more general question of "broadcasting" different domains implicitly has been discussed before and Alan Beccati filed #214 following that. That goes wider than this discussion but is related so I'm putting link here.