[GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

Thank you markus

On Wed, May 8, 2019 at 10:54 PM Markus Metz <markus.metz.giswork at gmail.com>
wrote:

> It depends. g.mapset changes the current mapset (and location and
> database). It might also create a new mapset in an existing location, but
> it always switches. If that switch is not desired, GISRC must be adjusted
> to the original GRASS session. G_make_mapset() is a C function and should
> be used by C modules. Of course you could use it with pygrass, but pygrass
> initializes the GRASS C libraries, and you need to take care that
> initializations are properly updated when changing mapsets (and locations).
> Creating a new mapset in an existing location is not difficult: create the
> folder and copy DEFAULT_WIND from PERMANENT to WIND in the new mapset.
> Maybe create a new function create_mapset() in lib/python/script/utils.py?
>

Generally speaking, I think it is important that the API comes first. Once
some functionality has been implemented in a library it can then be exposed
to the end users in multiple ways (e.g. CLI, REST, whatever). Among other
things, by implementing the API first, it is much easier to test the code +
you follow DRY.

This is why I mentioned "G_make_mapset()" which seems to already be
implementing this functionality and which, as you mentioned, is exposed to
Python via pygrass. The idea is that if in the future the process of
creating a mapset becomes more complicated, then we would only have to
update "G_make_mapset()". That being said I am not familiar enough with the
initialization process so I can't really argue if a pure python
implementation is needed or not.

Now to become more specific, as an API user, I think would find it strange
that calling the "create_mapset()" function also changes the current
mapset. I like it when things are explicit + it makes it easier to document
and test. As far as implementing "create_mapset()" in
lib/python/script/utils.py, why not move the relevant functions from
"gui/wxpython/startup/utils.py" and have the GUI code import them from the
"grass" lib?

BTW, those functions do need a few improvements; e.g. rename_mapset()
should fail to rename PERMANENT etc, but let's move them first and we can
do that later.


> >>> I adjusted the wxGUI startup wizard and the tests in trunk r74472,3
> (the tests should use g.mapset -c, not yet implemented)
> >
> >
> > I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND
> differ, so 74473 might break any tests that don't explicitly set the region
> themselves (which of course they should). We will see.
>
> IMHO, tests need to set the region themselves, just as users. The current
> region is such a fundamental concept of GRASS (raster processing) that I
> regard it as a mistake if the current region is not explicitly set to
> actual demands.
>

I completely agree that tests that don't set the region themselves should
be fixed.

all the best,
Panos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190509/b58ed80a/attachment.html>