NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Arliss- thanks! my comments are inline as well. Whiteside, Arliss E (US SSA) wrote:
- spatial subsetting: transformation of the request bbox to the native bbox may not be a bbox any more; (Arliss) Yes. However, the correct term is now BoundingBox, not bbox, see Subclause 10.2 of 05-008.
just my shorthand ;-)
- consequence: may need pixels "thrown away" during subsetting for proper resampling (Arliss) Not necessarily, depending on whether this bounding box means exact, minimum, or maximum. (need 2x subsetting in response description? personal note: hopefully not!) (Arliss) What do you mean by 2x subsetting?
let's consider this scenario: - first, we do subsetting according to the input coordinate in its CRS- then we do a coordinate transformation into the target CRS, which yields a non-bbox geometry. however the user expects a "full" data set, hence we have to subset enough pixels in step 1 that we can generate a "full" box in the target CRS. So in fact we must first subset "enough data" and then do the "exact" cutout. Additionally, if we specify eg bicubic interpolation we need to have a "halo" around the target data set to get correct data.
Note: Honestly, this is confusing for a naive reader - we have a "native" CRS of the coverage which is not explicitly mentioned (that's fine); we have a request CRS; we have a target CRS. Maybe we should explain this CRS mechanism somewhere? (Arliss) Yes, I think these CRSs should be explained somewhere. Indeed, there are two target CRSs, the (rectified) grid CRS and the base CRS in which that grid CRS is defined. Notice that this (rectified) grid CRS can be defined as being rotated and/or skewed in that base CRS. Also notice that this (rectified) grid CRS can be specified as a derived CRS, as specified in Clause 7 of Recommendation Paper 05-027r1 and in Clause 8 of proposed GML profile 05-096.
Why would the request CRS be other than either the native CRS or the target grid CRS? Although that may be possible, I think this should be rare.
While I agree with you that the full power will rarely be exercised I see the necessity that in the standard we describe all admissible requests and their consequences. Even though it's a tough challenge...
Indeed, I think we should consider prohibiting making the request CRS other than either the native CRS or the target grid CRS! Doing this should eliminate describing a separate request CRS.
Given the complexity WCS has already I am more than inclined to support that!
To accommodate this issue (thanks Ionic and USGS!) I have put reprojection to the very beginning. Although this probably is the least efficient sequencing in practice, it conceptually eases understanding for the nonexpert: all subsequent operations are carried out in the target CRS. And it avoids introducing 2x subsetting. (Arliss) I think using the term "reprojection" here is either incorrect or confusing. According to ISO 19111 and OGC Topic 2, the correct term is "coordinate transformation" or conversion. The normal meaning of the term "reprojection" is much more limited.
point taken. I will change the text accordingly.
Yes, showing this "coordinate transformation" at the beginning probably eases understanding. However, this is not inefficient if combined with the spatial and temporal subsetting as described below.
absolutely - not that any implementation would do that in practice. Therefore the preamble says that any WCS is free to choose its particular sequence, as long as the result is equivalent.
Which target CRS did you have in mind? I think this target CRS should be the target grid CRS, so no subsequent resampling is needed!
hm, do I get you right that the result should not have geo coordinates associated, even if the original coverage had one?
Indeed, I think we should specify that only one spatial resampling step be used by a WCS server, since use of more that one resampling step un-necessarily degrades image resolution, and also requires un-necessary resampling computations!
I agree about the undesirable numeric effects, but how can we achieve this?
In my opinion, this coordinate transformation can and should use a simplified form of the image resampling process described in Subclause 6.2 of my Discussion Paper 05-013. That is, for each pixel needed in the result grid CRS: a) Compute the position of this pixel, which is defined in result grid CRS, in the native CRS, using the proper coordinate transformation from the result grid CRS to the native CRS. b) Interpolate the value of this output pixel between the values of the surrounding pixels in the native CRS, and assign the interpolated value to this output pixel. Various interpolation methods can be used, including nearest-neighbor, bilinear, biquadratic, and bicubic.
can we adopt his? I will incorporate it in the description.
Notice that the "for each pixel needed in the result grid CRS" requires performomg this interpolation only for the spatial and temporal subsetting that is needed!
right, but that can be more pixels than indicated by the bbox
Further, as it stands there is considerable influence from the null values; in my draft I have assumed the null value semantics as outlined below in my proposal, to be explicit: the description actually relies on this semantics.- null value available for use by GetCoverage evaluation? (-> look into GetCoverage request spec and GetCap response spec)Results from looking into WCS 1.0 Corrigendum:- NullValues appear to be part of the CoverageOffering, so they are advertised & we can make use of them.- I don't like the NullValues section at all, here it is: --- snip --- NullValuesAn important part of a range set description is the representation of null value(s) in the coverage. The coverage encoding itself may specify a fixed value for null (e.g. "-99999" or "N/A"), but more often the choice is up to the provider and must be communicated to the client outside of the coverage itself. This is the purpose of the optional NullValues element, whose structure is depicted in Figure 15.NullValues is structured and interpreted exactly like the values element in AxisDescription (see Subclause 8.3.3.2.2).--- snip ---(Arliss) I point out two errors in the table in Subclause 10.4.1 of your attachment. The row for NullValue is not correct in the Definition and Data type columns. Also, this table requires a fourth column labeled Multiplicity, since this table serves as a data dictionary for the UML model.
ok, I will work on that.
In WCS 1.1 this text has moved into a footnote of Table 19, so its normative character is unclear to me. Let me propose to reinstantiate the null values section, given its importance. (Arliss) A footnote within a Table (or Figure) is always normative in an OGC (and ISO) specification! However, a page footnote (not within a Table or Figure) in never normative in an OGC (and ISO) specification.
hm, maybe more readers beside me are unaware of this fine line. May I suggest - to put the normative footnotes into regular paragraph texts, - to put the nonnormative footnotes into text paragraphs formatted as NOTE ... just to avoid misunderstandings
Issues:- we need just one null value per coverage, as opposed to the intervals allowed by AxisDescription - otherwise I guess about every client will be in despair. Let me propose to have a definition separate from AxisDescription. - what is "N/A"? "not applicable", likely - but what is the consequence? Does this value have normative character = every implementation must support it? How is it XML-encoded when only numeric parameters are admissible?- what is the "interpretation" in the 2nd para?- for the coverage evaluation it may be nice to have a word on the interpretation of any null value during response calculation. admittedly this will be redundant if we add the response description under preparation by me, but it wouldn't be the only place to be so, and I feel it adds some clarity.TODO: UnNamedDomainType in owsCOmmonIn particular I don't like this one: "[the null values] must be communicated to the client outside of the coverage itself". IMHO the null value is an important characteristics essential for proper data interpretation & further processing, and hence must be part of any coverage description, be it advertised as in GetCap or derived as in GetCov.enough whining - here my proposal for reintroducing the NullValue section: --- snip --- NullValuesEach coverage has an optional NullValue associated. When present, the NullValue denotes a reserved value of the coverage's range which shall be assigned to grid cells bearing no meaningful value. If the NullValue is missing then all possible values of the coverage's range shall be considered meaningful.Null values can eventually be involved in some arithmetics during preparation of a GetCoverage response when any of scaling, resampling, reprojection, or interpolation take place. During evaluation of said operations, a WCS server must ignore null values in its computations as long as there is at least one non-null value available for determining ; if all ingredient values needed for deriving the new value are null, then the result value shall be null too.--- snip ---(Arliss) In the above and in the attachment, you use the verb "must". However, in OGC (and ISO) specifications the correct normative verb is "shall", not "must".
thanks, will correct it.
Yes, at least one non-null value shall be used to determine a non-null value. I point out that the interpolation algorithm shall be very carefully applied when it would normally use one or more null values.
absolutely. and the necessary case distinctions will degrade performance (although normally I would not want to use a performance argument over functionality).
Further I propose to add a NullValue element also to the GetCoverage result.hm, looking at it again I feel that "sampling" may be less intuitive to the reader. What about "scaling and resampling"? I have rephrased it like that so that you can cath the flavour & comment. (Arliss) As I stated above, I think a separate "scaling and resampling" step can and should be omitted.- change in (spec + my doc) text: "scaling" -> "sampling"
I'd be happy about a simplification, but how would you concisely describe it? IMHO step a) above does not yet describe in enough detail what happens. As a sample use case let's take the question "what request parameters do I need to provide to get back the original, unchanged coverage data"?
- change in (spec + my doc) text: "interpolation" -> "spatial interpolation"done.- time subsetting and interpolation: needs further discussion- temporal subsetting:* we had the question: what is the resulting coverage like if, in the area selected spatiotemporally, the original coverage didn't have values / had null values? Meantime I think this is not a problem particular to the time axis, so I don't any longer feel the need for separate explanations. * for reasons of symmetry and functionality let me propose to add a grid selection mechanism for temporal subsetting, as it exists for spatial subsetting. I have added a change request.- temporal interpolation has been excluded, so nothing to do.- add text about time axis propertiesActually we see from the above that (i) the CRS switching and (ii) time axis handling are central issue which need more attention.So much for the current status. To better draw attention on the important issues I have split the Change Request Section into editorial and semantics.As always, I appreciate your comments / criticism / suggestions.
Dr. Peter Baumann - Professor of Computer Science, International University Bremen www.faculty.iu-bremen.de/pbaumann, mail: p.baumann@xxxxxxxxxxxx tel: +49-421-200-3178, fax: +49-421-200-49-3178 - Executive Director, rasdaman GmbH www.rasdaman.com, mail: baumann@xxxxxxxxxxxx tel: +49-89-67000146, fax: -67000147, mobile: +49-173-5837882 "A brilliant idea is a job halfdone."
galeon archives: