[GRASS-dev] Re: [GRASS GIS] #1507: r.in.gdal & others: -e must only modify the current mapset's WIND file

[GRASS GIS]

#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
---------------------------------------------+------------------------------
 Reporter:  hamish                           |       Owner:  grass-dev@…              
     Type:  defect                           |      Status:  new                      
 Priority:  blocker                          |   Milestone:  6.4.2                    
Component:  Default                          |     Version:  svn-trunk                
 Keywords:  r.in.gdal, r.external, v.in.ogr  |    Platform:  All                      
      Cpu:  All                              |  
---------------------------------------------+------------------------------

Comment(by hamish):

 Replying to [comment:11 glynn]:
 > Updating WIND only makes sense if the next step is to
 > copy WIND to somewhere more permanent (either DEFAULT_WIND
 > or a named region).

 IMO that choice is up to the user.. I don't know what makes sense to their
 task.  The use-case I was thinking about was so they could save the
 `g.region rast=new_map` or `g.region rast=new_map,old_map` step after
 import & so not wonder why the screen is white when they run `d.rast
 new_map` after the import seemed to go ok. In that case explicitly saving
 the expanded region is reproducible and there's no reason to save a copy
 of the new map's region alone as it can be recreated with `g.region rast=`
 whenever needed.


 > This opens up the issue of whether individual mapsets should
 > have a DEFAULT_WIND. Or, alternatively, whether "g.region -d"
 > and "g.region -s" should be synonyms for e.g. "g.region
 > region=default" and "g.region save=default" respectively (with
 > the former falling back to ../PERMANENT/DEFAULT_WIND if no
 > region named "default" exists).

 this is an interesting idea, it sounds useful and flexible & I'd support
 following it up in trunk.


 but for the immediate task of 6.4.2, how should we proceed?
 i.e. is everyone happy with the current way of r.in.gdal in trunk?
 (expands DEFAULT_WIND and WIND if in PERMANENT; sets WIND if not in
 permanent; a message describing what happened happens in all cases)
 if so we can sync with the other modules & branches. if not what do y'all
 suggest?


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1507#comment:12>
GRASS GIS <http://grass.osgeo.org>