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@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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev