[GRASS-dev] Hole / NULL filling module naming

Anna Petrášová kratochanna at gmail.com
Sat Nov 25 16:30:54 PST 2017


Hi,

On Wed, Apr 19, 2017 at 4:36 AM, Benjamin Ducke <benducke at 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.
>>
>> Wbr,
>> Māris.
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
>
> --
> Dr. Benjamin Ducke
> {*} Geospatial Consultant
> {*} GIS Developer
>
> Spatial technology for the masses, not the classes:
> experience free and open source GIS at http://gvsigce.org
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev


More information about the grass-dev mailing list