You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/02/15 15:47:03 UTC

Name change proposal: Range to Interval

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


Re: Name change proposal: Range to Interval

Posted by Adam Estrada <es...@gmail.com>.
Hi Martin,

I am not all that familiar with ISO 19123 but I do think that we need to
accommodate ISO terminology in SIS. I am completely open to anything that
you come up with...In other words, use your best judgement.

Thanks!
Adam


On Fri, Feb 15, 2013 at 9:47 AM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> 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
>
>

Re: Name change proposal: Range to Interval

Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris

Le 15/02/13 16:58, Mattmann, Chris A (388J) a écrit :
> * +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?
Yes, this is exactly that. In the projects I have seen up to date, this 
really help a lot in avoiding ambiguities.

> If so, +1.
Thanks.

> * As for the naming, let's be consistent with ISO and call it Interval
> then, which is fine.
Cool, I will proceed to renaming then.

     Martin


Re: Problem in renaming Range to Interval

Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 17/02/13 00:18, Mattmann, Chris A (388J) a écrit :
> +1 to:
>
> keep the class names as they stand today
> (with "Range" name everywhere) and explain in the javadoc the
> relationship with the ISO 19123 concept of "ranges"

This is probably the most reasonable thing to do. So let stick on that.

     Thanks for reading such long emails :-)

         Martin


Re: Problem in renaming Range to Interval

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,

+1 to:

keep the class names as they stand today
(with "Range" name everywhere) and explain in the javadoc the
relationship with the ISO 19123 concept of "ranges"


Cheers,
Chris

On 2/15/13 1:18 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:

>Hello all
>
>Reminder: the issue is about renaming "range" as "interval" in the
>"org.apache.sis.measure" package [1] for avoiding name clash with the
>ISO 19123 (Schema for coverage geometry and functions [2]) concept of
>range.
>
>I have trouble finding proper class names. We currently have:
>
>  * Range - a range of any kind of Comparables (not necessarily numeric).
>  * NumberRange - a range where Comparables are restricted to Numbers
>  * MeasurementRange - a NumberRange with a unit of measurement.
>
>
>The word "Interval" seems a perfect match for the current "NumberRange".
>The Wikipedia definition for "interval" [3] describes exactly the
>"NumberRange" behaviour: including/excluding endpoints, infinite
>endpoints, formatting... Even the discussion about whether infinite
>endpoints are inclusive or exclusive matches the NumberRange
>implementation choice :-). Problem is: "Interval" seems to be used
>exclusively for interval of numbers. For example I could easily find
>"character range" and "ordinal range" on Google, but have been unable to
>find "character interval" (or the definitions that I found were
>something completely different). While I found someone using the words
>"Numeric Interval" [4], this usage seems to be rare and do not answer
>the question "do non-numeric intervals exist?".
>
>Second problem: I couldn't find how to rename "MeasurementRange".
>Apparently, almost everyone on the web use the term "measurement
>interval" for another purpose (namely: the time elapsed between two
>measurements in a time series). Furthermore many web sites use
>"measurement range" for exactly what the "MeasurementRange" class is.
>Consequently renaming "MeasurementRange" as "MeasurementInterval" would
>probably cause a more severe confusion than the one we are trying to
>solve.
>
>In summary:
>
>  * Renaming "MeasurementRange" to "MeasurementInterval" seems out of
>    the question.
>  * Renaming "NumberRange" to "NumericInterval" would be okay.
>  * Renaming "Range" to "Interval" would be so-so, because "interval"
>    seems to imply "numeric interval" in the majority of cases.
>
>  So I'm tempted to either keep the class names as they stand today
>(with "Range" name everywhere) and explain in the javadoc the
>relationship with the ISO 19123 concept of "ranges", or either rename
>only "NumericRange" as "Interval" and leave all other names unchanged:
>
>  * pro:
>      o Class names "Range", "Interval" and "MeasurementRange" are the
>        most accurate names I can see for what those classes are.
>      o On those 3 above classes, "NumberRange" was by far the most
>        frequently used one, and renaming that class as "Interval" give
>        him a lovely name which is both short and mathematically accurate.
>      o In particular, the class used in context of ISO 19123
>        implementation will be mostly NumberRange, so renaming only that
>        class as "Interval" may be sufficient for avoiding a name clash
>        with the ISO 19123 concept of range.
>  * cons:
>      o The hierarchy would be "MeasurementRange extends Interval
>        extends Range". The "Interval" class name would look like a
>        foreigner in the middle of all those classes using the "Range"
>word.
>
>
>Any opinions?
>
>     Martin
>
>
>[1] 
>https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/measure
>/package-summary.html
>[2] http://www.opengeospatial.org/standards/as (topic 6)
>[3] http://en.wikipedia.org/wiki/Interval_%28mathematics%29
>[4] http://www.gabormelli.com/RKB/Numeric_Interval
>


Problem in renaming Range to Interval

Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all

Reminder: the issue is about renaming "range" as "interval" in the 
"org.apache.sis.measure" package [1] for avoiding name clash with the 
ISO 19123 (Schema for coverage geometry and functions [2]) concept of range.

I have trouble finding proper class names. We currently have:

  * Range - a range of any kind of Comparables (not necessarily numeric).
  * NumberRange - a range where Comparables are restricted to Numbers
  * MeasurementRange - a NumberRange with a unit of measurement.


The word "Interval" seems a perfect match for the current "NumberRange". 
The Wikipedia definition for "interval" [3] describes exactly the 
"NumberRange" behaviour: including/excluding endpoints, infinite 
endpoints, formatting... Even the discussion about whether infinite 
endpoints are inclusive or exclusive matches the NumberRange 
implementation choice :-). Problem is: "Interval" seems to be used 
exclusively for interval of numbers. For example I could easily find 
"character range" and "ordinal range" on Google, but have been unable to 
find "character interval" (or the definitions that I found were 
something completely different). While I found someone using the words 
"Numeric Interval" [4], this usage seems to be rare and do not answer 
the question "do non-numeric intervals exist?".

Second problem: I couldn't find how to rename "MeasurementRange". 
Apparently, almost everyone on the web use the term "measurement 
interval" for another purpose (namely: the time elapsed between two 
measurements in a time series). Furthermore many web sites use 
"measurement range" for exactly what the "MeasurementRange" class is. 
Consequently renaming "MeasurementRange" as "MeasurementInterval" would 
probably cause a more severe confusion than the one we are trying to solve.

In summary:

  * Renaming "MeasurementRange" to "MeasurementInterval" seems out of
    the question.
  * Renaming "NumberRange" to "NumericInterval" would be okay.
  * Renaming "Range" to "Interval" would be so-so, because "interval"
    seems to imply "numeric interval" in the majority of cases.

  So I'm tempted to either keep the class names as they stand today 
(with "Range" name everywhere) and explain in the javadoc the 
relationship with the ISO 19123 concept of "ranges", or either rename 
only "NumericRange" as "Interval" and leave all other names unchanged:

  * pro:
      o Class names "Range", "Interval" and "MeasurementRange" are the
        most accurate names I can see for what those classes are.
      o On those 3 above classes, "NumberRange" was by far the most
        frequently used one, and renaming that class as "Interval" give
        him a lovely name which is both short and mathematically accurate.
      o In particular, the class used in context of ISO 19123
        implementation will be mostly NumberRange, so renaming only that
        class as "Interval" may be sufficient for avoiding a name clash
        with the ISO 19123 concept of range.
  * cons:
      o The hierarchy would be "MeasurementRange extends Interval
        extends Range". The "Interval" class name would look like a
        foreigner in the middle of all those classes using the "Range" word.


Any opinions?

     Martin


[1] 
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/measure/package-summary.html
[2] http://www.opengeospatial.org/standards/as (topic 6)
[3] http://en.wikipedia.org/wiki/Interval_%28mathematics%29
[4] http://www.gabormelli.com/RKB/Numeric_Interval


Re: Name change proposal: Range to Interval

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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"
<ma...@geomatys.fr> 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
>