Hey Martin,
Totally get what you are talking about. A few points:
* +1 to using ranges instead of discrete values per vector. That would
mean,
e.g., for T = {t1, t2, ... , tN}, instead we would have:
T = {[t1s,t1e], [t2s, t2e], ... , [tNs, tNe]}
Correct?
If so, +1.
* As for the naming, let's be consistent with ISO and call it Interval
then, which is fine.
Cheers,
Chris
On 2/15/13 6:47 AM, "Martin Desruisseaux"
<[email protected]> wrote:
>Hello all
>
>A set of range-related classes (Range, NumericRange, MeasurementRange,
>RangeFormat, and RangeSet to arrive soon) have been committed. One
>purpose of those classes is to specify the values where data are
>available, typically as elevation (/z/) values or time (/t/) values.
>Many applications or file formats use single values for /z/ and /t/. For
>example NetCDF files typically specify the /z/ values of data slices in
>a "height" or "depth" vector, and /t/ values in a "time" vector. However
>I suggest to always work with ranges (or intervals) in Apache SIS
>mechanic. For example instead of specifying a single /t/ instant for any
>kind of data, we would always specify a [/start time/ ... /end time/]
>range (even if the range is very short in time, there is no
>instantaneous measurement). The rational are:
>
> * Consistency with the (/x/,/y/) dimensions: when specifying a
> bounding box, we implicitly specify range of values for the /x/ and
> /y/ dimensions. We are better to treat every dimensions in the same
>way.
> * Avoid tricky questions like "how far is it reasonable to
> interpolate?". If time were specified only as single /t/ values and
> if the user asks for data 3 days after the nearest time, how to know
> if it is reasonable to interpolate? If the data have a "/start
> time/" and "/end time/" instead, the question can be solved much
> more easily. This topic had been raised in a previous
> "Meteo-oceanography" meeting at OGC.
>
>
>Of course, user interfaces are free to replace ranges by single values
>in their widgets if they wish.
>
>However we have a minor name clash. This Range class were designed in
>old days before ISO 19123. Now, we have the ISO 19123 standard for
>Coverage features (which include rasters). If we consider a Coverage as
>a kind of function, then according ISO 19123 terminology the "/domain/"
>is the set of valid inputs (typically geodetic coordinates, but not
>necessarily) and the "/range/" is the set of valid outputs. So we have a
>risk of function between the Range class defined as a [/minimum/ ...
>/maximum/] tupple in the sis-utility module, and the "/range/" concept
>defined in ISO 19123 as the set of possible output values of a coverage
>(e.g. the set of pixel values in a raster).
>
>So we have a choice:
>
> * Keep the current Range name on the assumption that calling a
> [/minimum/ ... /maximum/] tupple a "range" is common enough to avoid
> confusion;
> * Rename Range into something else, for example Interval, in order to
> make Apache SIS fit better with ISO terminology (in this case,
> avoiding a name clash between two closely related concepts).
>
>Any opinion?
>
> Martin
>
