[GRASS-dev] [GRASS GIS] #2555: v.colors: silently ignores rules given at stdin

#2555: v.colors: silently ignores rules given at stdin
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.colors stdin | Platform: Unspecified
      Cpu: Unspecified |
----------------------------+-----------------------------------------------
{{{
v.colors map=censusblk_swwake use=attr column=MEDIAN_AGE rules=- << EOF
0% white
100% red
EOF
}}}

No color change in the map. However, if you create a rules file (called
'rules' here) with the same rules:

{{{
v.colors map=censusblk_swwake use=attr column=MEDIAN_AGE rules=rules
}}}

everything works as expected.

The reason is
[https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.colors/main.c#L282
main.c, lines 282ff] where the code handling the stdin case is just
commented without informing the user. IIUC, the problem is getting the min
and max values of the attribute or cats and of deciding whether the values
are floating point or not. For the first, the arraystats library offers
the AS_basic_stats function. For the latter, a simple check of the column
type should be enough (or = int if cat values are used).

Ideally this should be fixed, but if this is not possible, the option of
giving the rules at stdin should not be proposed in the interface
description and help page and there should be a message that this function
is currently not implemented. Silently ignoring is not a very user
friendly approach...

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2555&gt;
GRASS GIS <http://grass.osgeo.org>

#2555: v.colors: silently ignores rules given at stdin
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.colors stdin | Platform: Unspecified
      Cpu: Unspecified |
----------------------------+-----------------------------------------------

Comment(by annakrat):

I think, there is similar problem with option raster and volume (which
should be renamed if it's not yet). I agree this is confusing and should
be removed (I assume it's not super easy to implement?). Martin, any
opinion on that?

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

#2555: v.colors: silently ignores rules given at stdin
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.colors stdin | Platform: Unspecified
      Cpu: Unspecified |
----------------------------+-----------------------------------------------

Comment(by mlennert):

Replying to [comment:1 annakrat]:
> I think, there is similar problem with option raster and volume (which
should be renamed if it's not yet). I agree this is confusing and should
be removed (I assume it's not super easy to implement?). Martin, any
opinion on that?

The issue with copying from raster is different. I filed a separate
ticket: #2556.

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

#2555: v.colors: silently ignores rules given at stdin
----------------------------+-----------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-releasebranch70
Keywords: v.colors stdin | Platform: Unspecified
      Cpu: Unspecified |
----------------------------+-----------------------------------------------

Comment(by martinl):

Replying to [comment:2 mlennert]:
> Replying to [comment:1 annakrat]:
> > I think, there is similar problem with option raster and volume (which
should be renamed if it's not yet). I agree this is confusing and should
be removed (I assume it's not super easy to implement?). Martin, any
opinion on that?

I would just add fatal error that it's not supported yet and keep this
ticket open.

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