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