[GRASS-dev] Re: [GRASS GIS] #70: imagery modules: strip @mapset part

[Glynn Clements]

[Replying here because composing substantial responses in a 10-line
text widget with limited editing functionality and a single level of
undo is too much of a nuisance.]

GRASS GIS wrote:

>  > > It compares the wrong mapsets here (G_mapset() should possibly not
>  > > used on the left side, see function remove_subgroup_files() of main.c
>  of i.group.
>  >
>  > AFAICT, you should be able to use in=lsat7_2000_61 at landsat to acheive
>  the desired result.
> 
>  this is working but not practical. I could have generated the group some
>  years ago, for a normal user it's hard to find out this trick (yes, use -l
>  and such but...).

But what? "i.group -l" seems like exactly the right approach.

In any case, the existing behaviour (unqualified names are assumed to
be in the current mapset) has been around since at least 5.3 (I don't
have an older version to check). So this particular issue should
really have a separate ticket (as an "enhancement"); it's quite
distinct from the issue for which this ticket was originally opened.

>  Maybe: if a map appears only once in the list, remove it. Otherwise tell
>  the user to indicate the mapset.

Treating the name as a wildcard is definitely a bad idea; just because
there's only one match, that doesn't mean it's correct.

At least resolving it using the mapset search path is consistent with
the rest of GRASS, so it's less likely to (silently) have unexpected
consequences.

>  > Beyond that: unless "landsat" is in the mapset search path, this isn't a
>  bug; you '''should''' have to explicitly specify the @landsat part.
> 
>  It's not obvious (see above).

It may not be obvious; that doesn't mean that it isn't correct.

Actually, it seems (to me) to be a lot more obvious than treating the
name as a wildcard, given that's how every other module treats
unqualified names.

An unqualified name should only be considered as a typing shortcut,
and only when you already know *exactly* which qualified name it's a
shortcut for. Unqualified names aren't a substitute for knowing what
you're doing (nothing is).

>  > OTOH, in the case where it '''is''' in the mapset search path, it's a
>  limitation of the imagery library. The I_find_* functions only ever look
>  for files in the current mapset (passing a qualified name to I_find_* will
>  generate an error if the @mapset part doesn't specify the current mapset).
> 
>  AFAIK the imagery library was written in the early days of GRASS,
>  apparently improvements from libgis were never integrated.

In retrospect, I_find_* isn't relevant here. The names refer to raster
maps, not to groups or subgroups.

>  > Unlike the G_find_* functions, the I_find_* functions don't have a
>  mapset argument, so the caller doesn't get the option of passing
>  G_mapset() instead of "" to prevent the use of other mapsets. Bear in mind
>  that the same functions are used for both input (where other mapsets may
>  be used) and output (where only the current mapset may be used).
> 
>  Could the G_find_* functions be used instead?

In this specific case, G_find_* would be the correct function, as
these are raster map names.

For the I_find_* functions, I would tend towards adding a mapset
argument. There aren't that many callers which would need to be
changed, and a fair number of those are the I_fopen_* functions, which
have separate _new and _old versions.

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