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