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

#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:31 glynn]:
> Except: d.vect currently has both bgcolor= (label background color) and
bcolor= (label border colour). If these were changed to background_color
and border_color, bcolor would be rejected as ambiguous.

It has been already renamed to `label_bgcolor` and `label_bcolor` in
r62945.

> Another possibility with regards to abbreviating compound words would be
to use an upper-case letter (rather than a specific character, such as the
single quote in the previous example), so backGround_color would work like
back_ground_color but arguably isn't quite as ugly. Similarly, "columnS"
doesn't seem as bad as column_s.

I thought we have a rule not to use uppercase in key names. I would
personally keep it.

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

#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:33 annakrat]:
> Replying to [comment:31 glynn]:
> > Another possibility with regards to abbreviating compound words would
be to use an upper-case letter (rather than a specific character, such as
the single quote in the previous example), so backGround_color would work
like back_ground_color but arguably isn't quite as ugly. Similarly,
"columnS" doesn't seem as bad as column_s.
>
> Please don't do that. GRASS suffers from "too many ways to do the same
thing", let's not make it worse.

I would agree with Anna.

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

#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:19 wenzeslaus]:
> Replying to [comment:18 martinl]:
> > related to attachment:prefix_to_basename.diff
> >
> > I don't fully understand why to define key 'output' for basename
options. I thought that `G_OPT_BASENAME_OUTPUT` will have default key like
'basename_output' or 'output_basename' (better for backward
compatibility). Similarly `G_OPT_BASENAME_INPUT` 'input_basename'.
>
> Currently, it seems to me that the current option naming policy is to
use input or output regardless of type. So input can be raster for one
module but vector or imagery group for another. Basename is just another
item in the list of possible types/meanings.

OK, done in r62966

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

#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 mlennert):

Replying to [comment:30 glynn]:
> Replying to [comment:27 annakrat]:
> > I will change r.colors options (raster -> rast, volume -> rast3d)
unless someone is against, sometime soon.
>
> "raster" shouldn't be abbreviated.

+1

The problem is obviously more the inconsistency between modules than one
choice over the other, but I would also plead for unabbreviated keys
(unless absolutely infeasible).

Moritz

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

#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:39 mlennert]:

> > "raster" shouldn't be abbreviated.
>
> +1
>
> The problem is obviously more the inconsistency between modules than one
choice over the other, but I would also plead for unabbreviated keys
(unless absolutely infeasible).

right, this means to update `element_list`, see eg. inconsistency in

{{{
g.findfile -l
List of available elements:
   rast (raster map(s))
   rast3d (3D raster map(s))
   vect (vector map(s))
   oldvect (old (GRASS 5.0) vector map(s))
   asciivect (ASCII vector map(s))
   labels (paint label file(s))
   region (region definition(s))
   region3d (3D region definition(s))
   group (imagery group(s))
}}}

{{{
g.findfile element=vector
}}}

will not work...

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

#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:30 glynn]:
> Replying to [comment:27 annakrat]:
> > I will change r.colors options (raster -> rast, volume -> rast3d)
unless someone is against, sometime soon.
>
> "raster" shouldn't be abbreviated. "volume" should probably be
"raster_3d" (for which "raster3d" and "rast3d" are accepted
abbreviations).

I don't like "raster_3d". If we rename "rast" to "raster", which seems
reasonable, I would go with "raster3d", even though you can't shorten it.

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

#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 neteler):

Note: For testing the updated parameters, use at least r63176.

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

#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 neteler):

Replying to [comment:42 neteler]:
> Note: For testing the updated parameters, use at least r63176.

I have added a ODS table with remaining parameter issues after r63176 to
be fixed.

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

#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:41 annakrat]:
> > "raster" shouldn't be abbreviated. "volume" should probably be
"raster_3d" (for which "raster3d" and "rast3d" are accepted
abbreviations).
>
> I don't like "raster_3d". If we rename "rast" to "raster", which seems
reasonable, I would go with "raster3d", even though you can't shorten it.

in r63189 I renamed

{{{
      rast -> raster
      rast3d -> volume
      vect -> vector
      oldvect -> oldvector
      asciivect -> asciivect
}}}

It means that current abbreviated option will still work expect of
`rast3d` which needs to be renamed to `volume`.

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

#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:44 martinl]:

> in r63189 I renamed

btw, do we need `region3d` ? ASAIK the region is 3D by default. Martin

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

#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:44 martinl]:

{{{
> asciivect -> asciivect
}}}

I meant

{{{
        asciivect -> asciivector
}}}

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

#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:44 martinl]:
> Replying to [comment:41 annakrat]:
> > > "raster" shouldn't be abbreviated. "volume" should probably be
"raster_3d" (for which "raster3d" and "rast3d" are accepted
abbreviations).
> >
> > I don't like "raster_3d". If we rename "rast" to "raster", which seems
reasonable, I would go with "raster3d", even though you can't shorten it.
>
> in r63189 I renamed
>
> rast3d -> volume
>
> It means that current abbreviated option will still work expect of
`rast3d` which needs to be renamed to `volume`.

Why to volume? Although there was no agreement, we were often replacing
all "voxel" and "volumne" (and others) by "3D raster" so far. The only
three places I know about where "volume" is used are
[http://grass.osgeo.org/grass71/manuals/v.vol.rst.html v.vol.rst] (just
the name, not even the keyword), GUI menu/toolbox, and GUI for NVIZ.

I'm personally against "volume" because this term means too much other
things. (Does volume computations refer to 3D raster/voxels/voxel models
or to cubic meters of soil or water?) It even does not bring any
advantages for module family name (currently `r3`) which would be `v` but
`v` is already used.

If we are be replacing "3D raster", we should do it everywhere including
manual and module family name
([http://grass.osgeo.org/grass71/manuals/raster3D.html Manual: Raster3D
commands]).

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

#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:47 wenzeslaus]:
> > It means that current abbreviated option will still work expect of
`rast3d` which needs to be renamed to `volume`.
>
> Why to volume? Although there was no agreement, we were often replacing
all "voxel" and

I was discussing that with MarkusN and MarkusM and we didn't find a better
solution. Element 'volume' has big advantage: shorten 'rast' will still
work. Moreover 'rast3d' was somehow weird, "Volume" is used in the GUI
(menu).

> "volumne" (and others) by "3D raster" so far. The only three places I
know about where

"Voxel" is an element of the 3D grid. I would stay in the manual with "3D
raster map" or "volume map".

> I'm personally against "volume" because this term means too much other
things. (Does volume computations refer to 3D raster/voxels/voxel models
or to cubic meters of soil or water?) It

Feel free to suggest better solution. We don't want to use shorten element
names, we would prefer that shorten names will still work (`g.list rast`).

> If we are be replacing "3D raster", we should do it everywhere including
manual and module family name
([http://grass.osgeo.org/grass71/manuals/raster3D.html Manual: Raster3D
commands]).

No, I would stay with "3D raster map" or "volume map". We just changed
element list name, nothing else.

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

#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:48 martinl]:
> Replying to [comment:47 wenzeslaus]:
> > > It means that current abbreviated option will still work expect of
`rast3d` which needs to be renamed to `volume`.
> >
> > Why to volume? Although there was no agreement, we were often
replacing all "voxel" and
>
> I was discussing that with MarkusN and MarkusM and we didn't find a
better solution. Element 'volume' has big advantage: shorten 'rast' will
still work.

Sorry, but as you see I don't agree. Moreover, as I [comment:34 said
before], I don't see the point in making everything longer and then
thinking about how to shorten it. Well-decided short option/type name is
better.

If we would use `rast` and `rast3d` there wouldn't be any need to think
about shortening and thus no need to use something else than 3D raster.

> Moreover 'rast3d' was somehow weird,

Not for me, I don't say it's ideal but I considered it as good enough
(also for lack of other better options).

If something is weird to me, it is `r3` in the beginning of module names
because it has two characters not one. However, I haven't seen anything
which could be used to replace that (since both volume and voxel starts
with `v`).

> "Volume" is used in the GUI (menu).

And I always wanted to change that. `r3` is used in the name of the
modules.

> > "volume" (and others) by "3D raster" so far. The only three places I
know about where
>
> "Voxel" is an element of the 3D grid.

Sure, "voxel" is "3D pixel" and since pixel is a part of 2D raster, voxel
is a part of 3D raster.

> I would stay in the manual with "3D raster map" or "volume map".
> > If we are be replacing "3D raster", we should do it everywhere
including manual and module family name
([http://grass.osgeo.org/grass71/manuals/raster3D.html Manual: Raster3D
commands]).
>
> No, I would stay with "3D raster map" or "volume map". We just changed
element list name, nothing else.

That's the problem. This would only make the situation worse. Besides so
far favored "3D raster map" we would start to push also "volume map" and
I'm not even mentioning "voxel map" and "3D grid".
>
> > I'm personally against "volume" because this term means too much other
things. (Does volume computations refer to 3D raster/voxels/voxel models
or to cubic meters of soil or water?) It
>
> Feel free to suggest better solution. We don't want to use shorten
element names, we would prefer that shorten names will still work (`g.list
rast`).
>
My suggestion is not to make the options longer in any cost and rather use
reasonable shortcut as the only name. In case of rasters and 3D rasters it
is `rast` and `rast3d` which is even backwards compatible.

If we want users to learn that integer is `CELL` and double precision
floating point is `DCELL` then I believe they can also handle `rast` being
raster and `rast3d` being 3D raster.

Speaking about naming of 3D raster, with my suggestion, there is no need
to rename because there is no pressure for shortcuts. I would just
propagate 3D raster everywhere, solve in any way few issues with 3D being
at the beginning or at the end, and forgot about alternative names.

GRASS GIS is great because for rasters and vectors it is using the same
terms as computer graphics which is great because it is simple and
consistent. It is much better than some infamous software whose users are
calling digital elevation model image, polygons class, and data Shapefile.

Unfortunately, computer graphics does not offer a clear solution for
naming the thing which is the same as raster but in 3 dimensions. But what
about the simplest solution, 3D raster?

Even if there would be strong reason for renaming 3D raster (`rast3d`) to
something else, I would rather choose voxel instead of volume because
voxel is at least unambiguously related to 3D (voxel can be 3D pixel and
also some more complicated 3D computer graphics thing). It is true that
voxel is in fact "volume pixel" but "voxel map" clearly refers to 3D while
"volume map" can mean different things. I like "voxel map" in general
(much more than "volume map"). And as I said before, if rename, then
rename completely, so including the change of `r3` to `vo`. But I would
prefer to not go this way.

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

#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:49 wenzeslaus]:

> Sorry, but as you see I don't agree. Moreover, as I [comment:34 said
before], I don't see the point in making everything longer and then
thinking about how to shorten it. Well-decided short option/type name is
better.

shortly saying I don't see any problem to name the element as 'volume' and
use "3D raster map" in the manual and as element description..

{{{
g.list --help

        type Data type(s)
               options: raster,volume,vector,oldvector,asciivector,labels,
                        region,region3d,group,all
                raster: raster map(s)
                volume: 3D raster map(s)
                vector: vector map(s)
                oldvector: old vector map(s) (GRASS 5.0)
                asciivector: ASCII vector map(s)
                labels: paint label file(s)
                region: region definition(s)
                region3d: 3D region definition(s)
                group: imagery group(s)
                all: all types
}}}

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

#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:50 martinl]:
> Replying to [comment:49 wenzeslaus]:
>
> > Sorry, but as you see I don't agree. Moreover, as I [comment:34 said
before], I don't see the point in making everything longer and then
thinking about how to shorten it. Well-decided short option/type name is
better.
>
> shortly saying I don't see any problem to name the element as 'volume'
and use "3D raster map" in the manual and as element description..
>
I do.

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

#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:51 wenzeslaus]:

> > shortly saying I don't see any problem to name the element as 'volume'
and use "3D raster map" in the manual and as element description..
> >
> I do.

Anyone else has so clear idea about that?

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

#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:52 martinl]:
> Replying to [comment:51 wenzeslaus]:
>
> > > shortly saying I don't see any problem to name the element as
'volume' and use "3D raster map" in the manual and as element
description..

To me, this sounds like a possible source of confusion.

> > >
> > I do.
>
> Anyone else has so clear idea about that?

It seems that the only reason why you want 'volume' is to enable typing
'g.list rast', which isn't enough for me. If we wouldn't change rast to
raster, there would be no need to change rast3d to volume. So in my view
we ended up with something worse then we had before just because we
started to unabbreviate everything. I thought the initial idea was to fix
only apparently bad parameter names, but this is starting to have large
consequences - changes in scripts, manual pages, and confusing users.

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

#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:53 annakrat]:

> we started to unabbreviate everything. I thought the initial idea was to
fix only apparently bad parameter names, but this is starting to have
large consequences - changes in scripts, manual pages, and confusing
users.

with lookup table `old_key:new_key` we can quite easily fix all scripts
and manual pages. Also parser will understand `old_key` will continue to
work. We were planned to do cleanup some years ago, this ticket has been
open 3 months ago. I believe that it will has good consequences at the
end. We just need to finish the job. That's all.

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

#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:54 martinl]:
> Replying to [comment:53 annakrat]:
>
> > we started to unabbreviate everything. I thought the initial idea was
to fix only apparently bad parameter names, but this is starting to have
large consequences - changes in scripts, manual pages, and confusing
users.
>
> with lookup table `old_key:new_key` we can quite easily fix all scripts
and manual pages. Also parser will understand `old_key` will continue to
work. We were planned to do cleanup some years ago, this ticket has been
open 3 months ago. I believe that it will has good consequences at the
end. We just need to finish the job. That's all.

The purpose of unabbreviated options (and cleanup) is user friendliness
through manual and interface clearness. But the consequences of your
decision are two different terms for one thing. This is not user friendly
and thus it goes against the original motivation for the change.

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