[GRASS-dev] G7: how to get rid of multiple listing of identical map names?

[Glynn Clements]

Huidae Cho wrote:

> We have the same "new" issue in 6.4. I would just remove those warnings.
> 
> It looks like those warning messages are somehow related to r22844 by
> Glynn.

The only consequence of r22844 is that if a file is found in multiple
mapsets, the warnings identify all of the mapsets in which it was
found, not just the one being used.

The old version would print

	WARNING: 'cell/lsat5_1987_50' was found in more mapsets (also found in landsat3).

[The use of "also" is misleading, as that's the version which is
actually used.]

The new version prints

	WARNING: 'cell/lsat5_1987_50' was found in more mapsets (also found in landsat2).
	WARNING: 'cell/lsat5_1987_50' was found in more mapsets (also found in landsat).
	WARNING: Using <lsat5_1987_50 at landsat3>

The issue of the warning(s) being printed per-element rather than
per-map is a consequence of the check being performed in the library
rather than in the module. It applies equally to both the old and new
versions.

> The messages may be useful, but printing one warning per element for
> the same map is too much and the user doesn't need to know what element is
> being accessed. If we definitely want to show these similar messages, they
> should be per map, not per element per map to avoid too much and annoying
> verbosity.

It would be possible to avoid the per-element warnings by using
G_suppress_warnings() in the module to suppress warnings on all
elements after the first. However, that could suppress other warnings.

Or we could add something to lib/gis/find_file.c to control which
elements are eligible for these warnings (e.g. for a raster map, only
warning about the cellhd element should be sufficient).

Or we could keep track of the last such warning generated, and
suppress the warning if the map and mapset match those of the previous
warning.

> But still, IMHO, I don't see them *that* useful because the find_file
> returns the first file found in the search path based on a known and
> defined rule, which the user should already be familiar with.

People aren't computers. They don't necessarily know the current
mapset search path and/or the contents of those mapsets at all times. 
And even if they do, they may not always draw the relevant conclusions
from that information.

Without the warnings, it's entirely conceivable that a user could end
up unknowingly getting bogus results because a map which they intended
to use was "shadowed" by a map in another mapset.

And the rules aren't actually all that well defined. We've even had
developers bitten by oversights regarding the search path, i.e. 
assuming that a map which is known (or assumed) to exist in the
current mapset can be reliably accessed using an unqualified name.

This wasn't always the case, as the current mapset wasn't guaranteed
to be the first mapset in the search path. In the end, the code was
changed to force this to be the case, because expecting developers not
to make this mistake was considered unrealistic.

One consequence of this change is that the current mapset search path
isn't necessarily what the user set with "g.mapsets set=..."; the
current mapset will always be at the front of the list.

Another consequence is that changing the current mapset with g.mapset
will implicitly change the search path (the previous current mapset
will either revert to its specified position in the list, or be
removed from the search path, depending upon whether it was explicitly
part of the search path).

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