Hello list,
as r.fill.gaps add on got ported from G6, it sparked my interest in
hole (NULL area) filling. At the moment there is one dedicated tool
r.fillnulls, but I would put my +1 of moving r.fill.gaps to main trunk
(with some light changes). Still it raises a question - how it should
be named? And in more general - how other hole filling modules should
be named? Answer is not so easy, as current r.fillnulls is a Python
script thus any new C based method would result in a separate module.
One option would be splitting everything into separate modules based
on method/method group. Thus r.fillnulls could become i.e.
r.fill.spline (as at the moment all options are spline based) and
r.fill.gaps could become i.e. r.fill.stats. Such approach would allow
to add new C or Py modules as r.fill.idw, r.fill.nn, r.fill.nat etc.
Second option would be just integrate new methods into r.fillnulls. At
the moment module already is a wrapper script around other modules
thus adding extra methods + their parameter groups would not be too
hard thus not creating tens of small modules. Other plus would be
keeping its "cool"/easy to understand name. Downside of this approach
would be r.fillnulls becoming a real monster with a gazzillion of
parser options.
Of course, for the lifetime of G7, r.fillnulls will have to remain as
is to provide backwards compatibility.
Hello list,
as r.fill.gaps add on got ported from G6, it sparked my interest in
hole (NULL area) filling. At the moment there is one dedicated tool
r.fillnulls, but I would put my +1 of moving r.fill.gaps to main trunk
(with some light changes). Still it raises a question - how it should
be named? And in more general - how other hole filling modules should
be named? Answer is not so easy, as current r.fillnulls is a Python
script thus any new C based method would result in a separate module.
One option would be splitting everything into separate modules based
on method/method group. Thus r.fillnulls could become i.e.
r.fill.spline (as at the moment all options are spline based) and
r.fill.gaps could become i.e. r.fill.stats. Such approach would allow
to add new C or Py modules as r.fill.idw, r.fill.nn, r.fill.nat etc.
I would be in favour of that option.
A common naming scheme for modules with similar
purposes makes good sense.
Best,
Ben
Second option would be just integrate new methods into r.fillnulls. At
the moment module already is a wrapper script around other modules
thus adding extra methods + their parameter groups would not be too
hard thus not creating tens of small modules. Other plus would be
keeping its "cool"/easy to understand name. Downside of this approach
would be r.fillnulls becoming a real monster with a gazzillion of
parser options.
Of course, for the lifetime of G7, r.fillnulls will have to remain as
is to provide backwards compatibility.
On Wed, Apr 19, 2017 at 4:36 AM, Benjamin Ducke <benducke@fastmail.fm> wrote:
On 19/04/17 09:31, Maris Nartiss wrote:
Hello list,
as r.fill.gaps add on got ported from G6, it sparked my interest in
hole (NULL area) filling. At the moment there is one dedicated tool
r.fillnulls, but I would put my +1 of moving r.fill.gaps to main trunk
(with some light changes). Still it raises a question - how it should
be named? And in more general - how other hole filling modules should
be named? Answer is not so easy, as current r.fillnulls is a Python
script thus any new C based method would result in a separate module.
One option would be splitting everything into separate modules based
on method/method group. Thus r.fillnulls could become i.e.
r.fill.spline (as at the moment all options are spline based) and
r.fill.gaps could become i.e. r.fill.stats. Such approach would allow
to add new C or Py modules as r.fill.idw, r.fill.nn, r.fill.nat etc.
I would be in favour of that option.
A common naming scheme for modules with similar
purposes makes good sense.
coming back to this, I would like to put r.fill.gaps into 7.4. If
there is agreement on renaming it to r.fill.stats,
I can write a test and move it to the core. Related to this we should
probably consider renaming r.fill.dir to something like r.fill.sink in
grass 8.
I was wondering about the formula to compute the weights for spatially
weighted mean option, because in the manual it says it's equivalent to
IDW, but in fact, the weights are computed little bit differently
(1-d/maxd)^2, so should we still call it IDW?
Thanks,
Anna
Best,
Ben
Second option would be just integrate new methods into r.fillnulls. At
the moment module already is a wrapper script around other modules
thus adding extra methods + their parameter groups would not be too
hard thus not creating tens of small modules. Other plus would be
keeping its "cool"/easy to understand name. Downside of this approach
would be r.fillnulls becoming a real monster with a gazzillion of
parser options.
Of course, for the lifetime of G7, r.fillnulls will have to remain as
is to provide backwards compatibility.