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

[Glynn Clements]

Huidae Cho wrote:

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

Another option which I overlooked (but which has the same issue) is to
perform a single G_find_* call for a representative element, then pass
either an explicit mapset or a fully-qualified name in subsequent
calls.

In fact, r.info (which was the original example) already queries the
mapset, but only uses it for display.

This is a change from 6.x, which uses the found mapset when opening
support files (cats, history, etc). That was probably done when I
fixed the various library functions to consistently support the use of
fully-qualified names. The issue of multiple warnings (and a more
fundamental issue discussed below) didn't come up at that time.

Between the two, using a fully-qualified name would be preferable. 
Part of the reason for the original change was to eliminate the need
for modules to deal with mapsets explicitly. Functions which accept a
mapset argument should normally have "" as the mapset. The intent was
that the mapset argument could eventually be removed altogether.

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

The problem with that is that the memory requirements will grow over
time. And persistent applications such as QGIS will probably need some
way to reset the list.

OTOH, the "last warning" approach probably isn't good enough; modules
which process multiple maps often perform several iterations over the
list of maps: e.g. one for the cellhd for each map, one to open each
map, one to read the support files for each map.


But there's a rather more fundamental issue here: if G_find_file() is
called for an element which isn't guaranteed to exist for every map,
it will "find" the first map which actually contains that element,
which isn't necessarily the same map as for the other elements.

This doesn't affect the primary components of a map, because
Rast_open_old() first determines the mapset, then passes an explicit
mapset to the various G_open_* functions.

So, I think that G_find_file() etc should only be used in "find mode"
(with an empty mapset) for the "primary" element of a map (i.e. 
"cellhd" for raster maps, the map directory for vector maps). Other
components should be located by first finding the mapset, then using
the mapset to locate any additional components.

The old approach of having each module perform a G_find_file() to
determine the mapset avoided this issue, but placed the burden of
implementing this logic onto the individual modules (and some didn't,
meaning that they didn't handle fully-qualified names correctly).

A key issue is that G_find_file() is used for two distinct purposes:
one is finding maps (either by deconstructing fully-qualfied names or
by scanning the mapset search path), the other is generating the
filenames for the individual elements of a map.

These should probably be different functions (or rather, sets of
functions). But that may be too invasive (e.g. G_open_* etc implicitly
use G_find_file). A workaround would be to maintain a mapping which
connects an element name to a primary element, and always perform any
search for the primary element.

We might also want to avoid scanning the mapset search path repeatedly
for performance reasons, and maintaining a cache of found maps. If
that's done, the issue with multiple warnings would become moot. 
However, this also raises issues with regard to persistent
applications.

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