[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

GRASS GRASS developer
101

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by hcho):

Replying to [comment:80 wenzeslaus]:
> Replying to [comment:79 glynn]:
> > Replying to [comment:77 annakrat]:
> > > Replying to [comment:76 cmbarton]:
> > > > Could it cause a problem somewhere down the line to have this term
beginning with a number--e.g. If it is used to name a temp file or
something?
> > >
> > > As I already said, it causes problems for Python because keyword
parameter can't start with number. This is solvable by adding underscore
and some special handling of this case, which is partially there already.
It violates pep8.
> >
> > PEP8 is a style guide. There is no inherent reason why an argument
name cannot start with an underscore. And we're not even talking about
explicit arguments; such arguments will only ever be obtained via the
**kwargs mechanism.
>
> The problem may come once you want to use parameter as an variable or
member variable. In later case underscore would means private which is
technique not limited to Python. I'm also afraid that this can hit us or
somebody else in some other language or system. Almost nothing allows
numbers at the beginning of identifiers. I also think that for 3D raster
it is much more probable that you hit this issue. For example, how should
I name variable in my script which holds 3D raster map name or its
maximum? `_3draster_name`? `_3draster_max`? I can of course name my
variables whatever I want but wouldn't we stick to `rast3d` or `raster3d`
in the GRASS source code anyway?
>
> >
> > In fact, I think that this is why I chose to use a leading underscore
rather than a trailing underscore.
> >
> > Still, I'd rather avoid having option names start with a digit. But
unless we relax the ambiguity check, it wouldn't outweigh my preference to
avoid using an option name which has a very common option name (rast or
raster) as a prefix.
>
> I'm glad you are saying that. I think it is really important to state
the priorities and motivations. If we just want backwards compatibility,
then some special check in the parser can handle old short option names.
And if we value the most backwards compatibility and short options, we
probably should not not shorten at all in these special cases (type
names).
>
> Perhaps it is useful to ask why we want short options. It is for manual
typing? Well then we perhaps should use techniques used elsewhere. And we
are actually partially doing it. There is IDE-like auto-complete in GUI,
Python dir completed is implemented for PyGRASS module interface and of
course Linux command line auto-completes module names. So why not to take
it further and auto-complete also parameters and perhaps other things by
implementing auto-complete for shell?
>
> Classic unix-like command line is anyway the only place where short
options really matter if you consider the things above and also that you
should not use shortened option names in scripts because it is not
readable (that's why we are unabbreviating them, right?).
>
> Perhaps we don't have to unabbreviate everything. It seems to me that
there is no will to unabbreviate options for `g.region` or module names
containing rast, vect or rast3d. I'm for explicit long descriptive option
names but if it creates more issues then it solves (`3draster`) and if
everybody would be using the shortened version all the time anyway
(`rast`, ...), I prefer not to change them.
>

I strongly agree with you. Personally, I'm fine with the old type names.
If shortening rast3d= is an issue because of conflicts with rast=, we
could change it to volume= or voxel= (and vo.* module names). I don't
think it's a good idea to have to type an underscore before certain option
names in Python or possibly other languages and we could avoid such
annoying/inconsistent situations by naming elements more carefully.

> If we want short options for whatever reason, let's standardize them,
rather than standardize the long options and provide ways how to avoid the
standard.

+1

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:81&gt;
GRASS GIS <http://grass.osgeo.org>

102

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by glynn):

Replying to [comment:80 wenzeslaus]:

> Perhaps we don't have to unabbreviate everything. It seems to me that
there is no will to unabbreviate options for `g.region` or module names
containing rast, vect or rast3d.

FWIW, I would like to unabbreviate everything which could reasonably be
unabbreviated (including raster and vector rather than rast and vect).
Clearly, there are cases where this would be unreasonable (e.g. option
names may contain acronyms which could expand to several words, some of
which may be long compound words, or may themselves be acronyms).

> I'm for explicit long descriptive option names but if it creates more
issues then it solves (`3draster`) and if everybody would be using the
shortened version all the time anyway (`rast`, ...), I prefer not to
change them.

Code should always use the full name. Abbreviations are intended for
interactive use.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:82&gt;
GRASS GIS <http://grass.osgeo.org>

103

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by glynn):

Replying to [comment:81 hcho]:

> I don't think it's a good idea to have to type an underscore before
certain option names in Python or possibly other languages and we could
avoid such annoying/inconsistent situations by naming elements more
carefully.

There are two reasons why an option name cannot be used in Python. One is
if it doesn't conform to the syntax for an identifier (e.g. starts with a
digit). The other is if it is a reserved word (e.g. "from").

Avoiding the first case is simple enough. A requirement that option names
begin with a letter and consist solely of letters, digits and underscores
will ensure conformance with the identifier syntax for any common
language.

The second one is more awkward, as different languages have different sets
of reserved words. The only real constant is that many of them are quite
common words which would frequently be an ideal choice for an option name.

I'm not sure that we should reject such names simply because they can't be
used as a variable/parameter/etc name in a specific language without a
tweak such as adding an underscore (or changing case; now that option
names are limited to lower-case, having grass.script.make_command() force
each name to lower case would be feasible).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:83&gt;
GRASS GIS <http://grass.osgeo.org>

104

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

Replying to [comment:82 glynn]:
> Replying to [comment:80 wenzeslaus]:
> > I'm for explicit long descriptive option names but if it creates more
issues then it solves (`3draster`) and if everybody would be using the
shortened version all the time anyway (`rast`, ...), I prefer not to
change them.
>
> Code should always use the full name. Abbreviations are intended for
interactive use.

This is what I mean. If we want better interactive use, let's improve it
but not at expense of writing the code. (`3draster` is improvement for
interactive use but it makes code worse by requiring `_3draster`.)

As I said before, short options are mostly advantageous for unix-like
command lines, so let's use what it used there, the Tab key auto-complete.
This is definitively not an obsolete thing, for example Git is using it
extensively, SVN supports it too.

Another solution for abbreviating `raster` and `raster3d` which solves the
problem at the level of abbreviating and does not make the code worse
(although it might harm a little bit) is changing the ambiguity rules as
[comment:75 Glynn suggested in comment 75]. My first impression from
shortening actually was that it counts matching letters for each option
and gives a best match. But this is not (unlike Tab key auto-complete)
completely isolated from calling the modules from some code, so I'm afraid
of two things. First, that it can become dangerous for people not using
the long options in the code (e.g. for compatibility reasons). Second,
that the option matching can become so costly that it would actually make
module calls more expensive.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:84&gt;
GRASS GIS <http://grass.osgeo.org>

105

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by huhabla):

I full agree with Vaclav.

However, the modification of GRASS was already performed, regardless the
fact that we still discuss the renaming of rast, rast3d and vect options.

This, as i already stated before, completely broke the temporal framework.
It is not only a matter of renaming option names, the whole internal
temporal data type system and handling of different map types was broken
because of this. What to do now with temporal module names? Must t.rast.*
modules be renamed into t.raster.*? Or t.rast3d.* modules into
t.3draster.*?

Someone tried to fix the framework by simply renaming rast3d into
3draster, but this did not solved the problem. The framework was still
broken. Why was the testsuite not used to check these changes? Why do we
have the test-framework anyway?
Just a tiny hint: renaming the option "n" from v.random into "npoints"
broke plenty of temporal vector module tests, since they are using PyGRASS
to call v.random and PyGRASS can't handle abbreviations.

I needed 5 hours to fix the temporal framework and i am pretty sure that i
did not catch all issues that were introduced with the renaming.

Putting GRASS in such broken a state without using the testuite to write
and use tests or at least to verify the changes with existing tests is
IMHO irresponsible. Especially if we plan to make a beta release.

I am sorry for my harsh words, but i had to invest 5h for no good reason
to keep on with my regular work.

Replying to [comment:80 wenzeslaus]:
> Replying to [comment:79 glynn]:
> > Replying to [comment:77 annakrat]:
> > > Replying to [comment:76 cmbarton]:
> > > > Could it cause a problem somewhere down the line to have this term
beginning with a number--e.g. If it is used to name a temp file or
something?
> > >
> > > As I already said, it causes problems for Python because keyword
parameter can't start with number. This is solvable by adding underscore
and some special handling of this case, which is partially there already.
It violates pep8.
> >
> > PEP8 is a style guide. There is no inherent reason why an argument
name cannot start with an underscore. And we're not even talking about
explicit arguments; such arguments will only ever be obtained via the
**kwargs mechanism.
>
> The problem may come once you want to use parameter as an variable or
member variable. In later case underscore would means private which is
technique not limited to Python. I'm also afraid that this can hit us or
somebody else in some other language or system. Almost nothing allows
numbers at the beginning of identifiers. I also think that for 3D raster
it is much more probable that you hit this issue. For example, how should
I name variable in my script which holds 3D raster map name or its
maximum? `_3draster_name`? `_3draster_max`? I can of course name my
variables whatever I want but wouldn't we stick to `rast3d` or `raster3d`
in the GRASS source code anyway?
>
> >
> > In fact, I think that this is why I chose to use a leading underscore
rather than a trailing underscore.
> >
> > Still, I'd rather avoid having option names start with a digit. But
unless we relax the ambiguity check, it wouldn't outweigh my preference to
avoid using an option name which has a very common option name (rast or
raster) as a prefix.
>
> I'm glad you are saying that. I think it is really important to state
the priorities and motivations. If we just want backwards compatibility,
then some special check in the parser can handle old short option names.
And if we value the most backwards compatibility and short options, we
probably should not not shorten at all in these special cases (type
names).
>
> Perhaps it is useful to ask why we want short options. It is for manual
typing? Well then we perhaps should use techniques used elsewhere. And we
are actually partially doing it. There is IDE-like auto-complete in GUI,
Python dir completed is implemented for PyGRASS module interface and of
course Linux command line auto-completes module names. So why not to take
it further and auto-complete also parameters and perhaps other things by
implementing auto-complete for shell?
>
> Classic unix-like command line is anyway the only place where short
options really matter if you consider the things above and also that you
should not use shortened option names in scripts because it is not
readable (that's why we are unabbreviating them, right?).
>
> Perhaps we don't have to unabbreviate everything. It seems to me that
there is no will to unabbreviate options for `g.region` or module names
containing rast, vect or rast3d. I'm for explicit long descriptive option
names but if it creates more issues then it solves (`3draster`) and if
everybody would be using the shortened version all the time anyway
(`rast`, ...), I prefer not to change them.
>
> If we want short options for whatever reason, let's standardize them,
rather than standardize the long options and provide ways how to avoid the
standard.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:85&gt;
GRASS GIS <http://grass.osgeo.org>

106

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by martinl):

Replying to [comment:85 huhabla]:
> I needed 5 hours to fix the temporal framework and i am pretty sure that
i did not catch all issues that were introduced with the renaming.

sorry for that, *BUT* we were speaking about consolidation of parameters
*MANY YEARS* ago! But *NOTHING* really *CHANGED* till now. I agree with
you that we are too late with that but I still think that it made sense to
do it.

> Putting GRASS in such broken a state without using the testuite to write
and use tests or at least to verify the changes with existing tests is
IMHO irresponsible. Especially if we plan to make a beta release.

See my note above...

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:86&gt;
GRASS GIS <http://grass.osgeo.org>

107

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by huhabla):

Replying to [comment:86 martinl]:
> Replying to [comment:85 huhabla]:
> > I needed 5 hours to fix the temporal framework and i am pretty sure
that i did not catch all issues that were introduced with the renaming.
>
> sorry for that, *BUT* we were speaking about consolidation of parameters
*MANY YEARS* ago! But *NOTHING* really *CHANGED* till now. I agree with
you that we are too late with that but I still think that it made sense to
do it.
>
> > Putting GRASS in such broken a state without using the testuite to
write and use tests or at least to verify the changes with existing tests
is IMHO irresponsible. Especially if we plan to make a beta release.
>
> See my note above...

Dear Martin,
many thanks for all of your effort.

I am not arguing about the sense of the changes. As i stated before i am
fine with them. I simply have a problem how these changes are applied. We
have a wonderful test suite that will help you to avoid breaking parts of
GRASS. We should make use of it to avoid such a discussion.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:87&gt;
GRASS GIS <http://grass.osgeo.org>

108

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by martinl):

Replying to [comment:87 huhabla]:
> many thanks for all of your effort.

personally I am not happy with these changes too. They should have been
done much more earlier, now it's very late. But still I think it's better
than not to do it at all. Anyway I am not happy about this situation.

> I am not arguing about the sense of the changes. As i stated before i am
fine with them. I simply have a problem how these changes are applied. We
have a wonderful test suite that will help you to avoid breaking parts of
GRASS. We should make use of it to avoid such a discussion.

Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference

{{{
raster3d*
volume
3draster
}}}

(*) Then we could modify parser to understand also `rast` and `rast3d`
with appropriate warning

{{{
g.list rast
WARNING: Element <rast> has been renamed <raster>. Please update your
script.
...

g.list rast3d
WARNING: Element <rast3d> has been renamed <raster3d>. Please update your
script.
...
}}}

What do you think?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:88&gt;
GRASS GIS <http://grass.osgeo.org>

109

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by glynn):

Replying to [comment:84 wenzeslaus]:

> As I said before, short options are mostly advantageous for unix-like
command lines, so let's use what it used there, the Tab key auto-complete.

We shouldn't rely upon this feature being available. And even when it is,
it's not automatically better than abbreviation (e.g. completion is
affected by latency, abbreviation isn't).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:89&gt;
GRASS GIS <http://grass.osgeo.org>

110

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by glynn):

Replying to [comment:88 martinl]:

> Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
>
{{{
raster3d*
volume
3draster
}}}

My preference would be "volume"; the other two have issues. We can debate
forever about how significant those issues are, but "volume" avoids them
entirely.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:90&gt;
GRASS GIS <http://grass.osgeo.org>

111

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

Replying to [comment:90 glynn]:
> Replying to [comment:88 martinl]:
>
> > Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
> >
> {{{
> raster3d*
> volume
> 3draster
> }}}
>
> My preference would be "volume"; the other two have issues. We can
debate forever about how significant those issues are, but "volume" avoids
them entirely.

`volume` avoids issues with naming variables but creates issues when
talking with people. From my experience, volume is very confusing while 3D
raster (-> `raster3d`) works because it is very explanatory and it is not
a [http://en.wikipedia.org/wiki/Homonym homonym]. Voxel seems not be an
option anymore but it is a term which people react to time to time because
it is at least clear that it is something special (not a
[http://en.wikipedia.org/wiki/Volume volume] in liters).

BTW, Wikipedia is not really helpful in deciding about
`volume`/`voxel`/`raster3d` but it links not really related
[http://skuld.bmsc.washington.edu/raster3d/raster3d.html Raster3D]
software ([http://en.wikipedia.org/wiki/Raster_graphics#External_links
Raster graphics]) and it talks about ''2D and 3D raster and vector'' when
it is describing a book
[http://en.wikipedia.org/wiki/Computer_Graphics:_Principles_and_Practice#Second_Edition
Computer Graphics: Principles and Practice] which is highly related.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:91&gt;
GRASS GIS <http://grass.osgeo.org>

112

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by annakrat):

Replying to [comment:90 glynn]:
> Replying to [comment:88 martinl]:
>
> > Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
> >
> {{{
> raster3d*
> volume
> 3draster
> }}}
>
> My preference would be "volume"; the other two have issues. We can
debate forever about how significant those issues are, but "volume" avoids
them entirely.

So if we decide for volume, do we plan to rename all modules like this? If
not, we should stay with raster3d. Otherwise it will get very confusing in
my opinion.

{{{
r3.info -> vo.info
r.to.rast3-> t.to.volume
}}}
I must say I am not particularly fond of vo.* modules, but maybe it's just
a matter of habit.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:92&gt;
GRASS GIS <http://grass.osgeo.org>

113

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by hcho):

Replying to [comment:90 glynn]:
> Replying to [comment:88 martinl]:
>
> > Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
> >
> {{{
> raster3d*
> volume
> 3draster
> }}}
>
> My preference would be "volume"; the other two have issues. We can
debate forever about how significant those issues are, but "volume" avoids
them entirely.

+1 for volume (+2 for voxel) for the exact same reason.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:93&gt;
GRASS GIS <http://grass.osgeo.org>

114

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by martinl):

Replying to [comment:93 hcho]:
> +1 for volume (+2 for voxel) for the exact same reason.

-1 for voxel, than we could rename 'raster' to 'pixel' :wink:

I am still not sure we need to rename than all modules from `r3` to
`vo`...

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:94&gt;
GRASS GIS <http://grass.osgeo.org>

115

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by helena):

Replying to [comment:94 martinl]:
> Replying to [comment:93 hcho]:
> > +1 for volume (+2 for voxel) for the exact same reason.
>
> -1 for voxel, than we could rename 'raster' to 'pixel' :wink:
>
> I am still not sure we need to rename than all modules from `r3` to
`vo`...

so is there also an agreement to rename all r3.* commands to vo.* commands
and changing all manuals accordingly? If yes, this will require several
weeks of focused testing and reviews/updates of all grass7 related
manuals, tutorials and scripts.I don't have a good solution for this issue
but I am not a big fan of changing names unless it is absolutely necessary
or leads to a major improvement. Reading through the discussion I am
wondering whether anybody has done a solid research on what are the 3D
rasters referred to in different disciplines and which term is closest to
our users backgrounds or are all these three names that are being
considered based on what each individual thinks is right? Which brings me
to another point - is this being discussed on the users list as well? The
users will be the ones most affected (and potentially confused) so why not
get some feedback from them?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:95&gt;
GRASS GIS <http://grass.osgeo.org>

116

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by martinl):

Replying to [comment:95 helena]:
> > -1 for voxel, than we could rename 'raster' to 'pixel' :wink:
> >
> > I am still not sure we need to rename than all modules from `r3` to
`vo`...
>
> so is there also an agreement to rename all r3.* commands to vo.*
commands and changing all manuals accordingly? If yes, this will require
several weeks of focused testing and

not at all, personally I don't like to stick with shortened element names
(rast, rast3d) just because it makes our life easier. Taking in account a
real world it seems to me that the reasonable is to rename `rast ->
raster` and `rast3d -> raster3d` and to modify the parser to understand
also shortened element names.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:96&gt;
GRASS GIS <http://grass.osgeo.org>

117

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by cmbarton):

Can raster_3D be better parsed in long and shortened form?

Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:97&gt;
GRASS GIS <http://grass.osgeo.org>

118

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by annakrat):

Replying to [comment:97 cmbarton]:
> Can raster_3D be better parsed in long and shortened form?
>
It has the same issues as raster3d, still rast is ambiguous. You can
shorten raster_3D to rast3d or r3 but you can't shorten raster.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:98&gt;
GRASS GIS <http://grass.osgeo.org>

119

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by huhabla):

Replying to [comment:96 martinl]:
> Replying to [comment:95 helena]:
> > > -1 for voxel, than we could rename 'raster' to 'pixel' :wink:
> > >
> > > I am still not sure we need to rename than all modules from `r3` to
`vo`...
> >
> > so is there also an agreement to rename all r3.* commands to vo.*
commands and changing all manuals accordingly? If yes, this will require
several weeks of focused testing and
>
> not at all, personally I don't like to stick with shortened element
names (rast, rast3d) just because it makes our life easier. Taking in
account a real world it seems to me that the reasonable is to rename `rast
-> raster` and `rast3d -> raster3d` and to modify the parser to understand
also shortened element names.

This would be absolutely my favorite solution.

IMHO renaming all 3D raster and STR3DS modules using "volume" name
approach will result in a lot of unnecessary work and inconsistency. As a
result all documentation in code and manual pages, the module help,
examples and tests must be updated/modified as well. Not speaking about
the confusion with wording in already published scientific papers and
books ... .

I don't think this is worth the effort.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:99&gt;
GRASS GIS <http://grass.osgeo.org>

120

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------+-----------------------------------------

Comment(by martinl):

Replying to [comment:99 huhabla]:
> > not at all, personally I don't like to stick with shortened element
names (rast, rast3d) just because it makes our life easier. Taking in
account a real world it seems to me that the reasonable is to rename `rast
-> raster` and `rast3d -> raster3d` and to modify the parser to understand
also shortened element names.
>
> This would be absolutely my favorite solution.

please could you try attachment:raster3d.diff. Does it make sense to you?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:100&gt;
GRASS GIS <http://grass.osgeo.org>