[GRASS-dev] standarizing range syntax

GRASS GRASS developer
1

Currently, due to its history, GRASS has various ways of designating a range of values.

In raster displays (d.rast) ranges are expressed as 'n-n';
for color tables, they are implied but not explicitly given;
for raster reclass maps (r.reclass), they are expressed as 'n thru n'
for raster recode (r.recode), they are expressed as 'n:n';
for vector reclass (actually a recode, v.reclass), ranges are expressed in SQL syntax

At least for rasters, I'd like to suggest that we standardize range notation.

I recommend 'n-n'. It is compact, widely recognized, and doesn't use a misspelled english word ("thru"). The syntax 'n:n' is used in some programming, but not a lot beyond that.

I suppose that each module might also accept it's old non-standard syntax, too, to maintain backward compatibility for scripts.

Michael

2

Michael Barton wrote:

Currently, due to its history, GRASS has various ways of designating a
range of values.

In raster displays (d.rast) ranges are expressed as 'n-n';
for color tables, they are implied but not explicitly given;
for raster reclass maps (r.reclass), they are expressed as 'n thru n'
for raster recode (r.recode), they are expressed as 'n:n';
for vector reclass (actually a recode, v.reclass), ranges are
expressed in SQL syntax

At least for rasters, I'd like to suggest that we standardize range
notation.

I recommend 'n-n'. It is compact, widely recognized, and doesn't use a
misspelled english word ("thru"). The syntax 'n:n' is used in some
programming, but not a lot beyond that.

One issue with "m-n" is that it could be quite easy to inadvertently
write code which doesn't handle negative values correctly, e.g.
"-10--5". IMHO, it's also less clear than "-10:-5".

--
Glynn Clements <glynn@gclements.plus.com>

3

On Aug 12, 2008, at 10:29 PM, Glynn Clements wrote:

Michael Barton wrote:

Currently, due to its history, GRASS has various ways of designating a
range of values.

In raster displays (d.rast) ranges are expressed as 'n-n';
for color tables, they are implied but not explicitly given;
for raster reclass maps (r.reclass), they are expressed as 'n thru n'
for raster recode (r.recode), they are expressed as 'n:n';
for vector reclass (actually a recode, v.reclass), ranges are
expressed in SQL syntax

At least for rasters, I'd like to suggest that we standardize range
notation.

I recommend 'n-n'. It is compact, widely recognized, and doesn't use a
misspelled english word ("thru"). The syntax 'n:n' is used in some
programming, but not a lot beyond that.

One issue with "m-n" is that it could be quite easy to inadvertently
write code which doesn't handle negative values correctly, e.g.
"-10--5". IMHO, it's also less clear than "-10:-5".

OK. What about "m to n"?

Michael

4

Michael Barton wrote:

Currently, due to its history, GRASS has various ways of designating a
range of values.

In raster displays (d.rast) ranges are expressed as 'n-n';
for color tables, they are implied but not explicitly given;
for raster reclass maps (r.reclass), they are expressed as
'n thru n' for raster recode (r.recode), they are expressed as
'n:n'; for vector reclass (actually a recode, v.reclass),
ranges are expressed in SQL syntax

At least for rasters, I'd like to suggest that we
standardize range notation.

I recommend 'n-n'. It is compact, widely recognized, and doesn't use a
misspelled english word ("thru"). The syntax 'n:n' is used in some
programming, but not a lot beyond that.

v.extract user the standard parser option G_OPT_V_CATS:
    list Category values
            Example: 1,3,7-9,13

which I think is fine; cat ranges never fall into the negative.

r.category's cats= option is the same, but its rules file format uses
  cat:Label
or
  val1:val2:Label

r.reclass format is a bit weird, I don't mind changing that.

r.colors rules are used bit differently, so they may not fall into the
scope of this standardization round.

I assume vector modules which take SQL statements do not parse those
statements but pass them intact, in which case I would leave them
as-is.

I would not touch this for grass6, and not stress too much about backwards
compatibility for grass7.

2c,
Hamish