[GRASS-dev] Re: [GRASS GIS] #1507: r.in.gdal & others: -e must only
modify the current mapset's WIND file
GRASS GIS
trac at osgeo.org
Wed Dec 14 07:49:00 EST 2011
#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:2 neteler]:
> I am not at all convinced that this change in known behaviour
> should reach GRASS 6.4.
my take on it--
backwards compatibility is allowed to be broken in cases where the
previous behaviour was clearly in error and harming the user. in this case
we have the competing interests of conserving expected behaviour (warts
and all) versus the fact that the previous behaviour was is serious
violation of the rule where modules are only allowed to make modifications
within the current mapset. to allow that risks mayhem in a
classroom/research team multi-user environment with a shared PERMANENT
[can't trust file system write permissions to save us].
(modifying newly created locations/mapsets outside of the current one is
of course ok -- but only during the process of creating them)
the decision of which of those two interests is more important is based on
how bad the design bug was and how core or peripheral the feature change
will be. there's no correct answer, just a judgment call. either way we
win somehow, either way we lose somehow.
In this case I would not be too surprised if someone had a processing
script expecting the old behaviour, which is quite unfortunate, but for my
2c I think the gross violation of g.access rules is the worse of the two
options.
certainly if we decide to backport this to 6.4 it should feature
prominently in the release notes.
> AFAIK the functionality is there on purpose...
what was it? I mean versus having the module change the current WIND file
only? If it is for r.in.gdal & v.in.ogr & newly created locations it's
already taken care of, because G_make_location() takes &cellhd as one of
its function argument and so the new DEFAULT_WIND and WIND are already set
to match the import map's bounds.
best,
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1507#comment:3>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list