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

[Huidae Cho]

On Mon, Jun 23, 2014 at 6:54 AM, Glynn Clements <glynn at gclements.plus.com>
wrote:

>
> 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.
>

I'm against this idea for that reason and because we have to change modules.


>
> 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).
>

We could pick one representative element, which must be open first (cellhd
for raster, head for vector, ... for others?) and print only mapset names
per map. However, if the search path changes between find_file calls and we
print only the first warning for the same map, we can miss some mapsets
added later or, in the worst case, it may not print an important "reminder"
when really needed.


> 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.
>
>
Not just the last such warning because we never know when the same map will
be accessed again from a module. E.g., cellhd/raster1, cellhd/raster2,
cell/raster1, cell/raster2.

In any case, we can take advantage of further aggregating the warning into
one each time (either per-element or per-map):

WARNING: <lsat5_1987_50> raster map was also found in <landsat2> and
<landsat>. Using <lsat5_1987_50 at landsat3>.


> > 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140623/f38d9bf5/attachment-0001.html>