Re: [GRASS-dev] r.fill.gaps porting

On Sat, Apr 15, 2017 at 8:32 AM, Benjamin Ducke wrote: > The thing is: I originally developed this module for > gradiometer data. That data is very noisy and has > high local variation. Interpolating that type of > data while preserving original measurements will > usually

Re: [GRASS-dev] r.fill.gaps porting

On Apr 15, 2017 5:47 PM, "Maris Nartiss" wrote: > It is correct as it resizes the width not height of image. There is a > wrong assumption that setting width automatically should set also > height. Not according to HTML spec (proportional scaling is not > mandated). Thus

Re: [GRASS-dev] r.fill.gaps porting

2017-04-15 16:13 GMT+03:00 Markus Neteler : > >> Supposedly, the wxPython HTML renderer >> does not apply "width=" correctly and does not >> resize the image on the fly. It is correct as it resizes the width not height of image. There is a wrong assumption that setting width

Re: [GRASS-dev] r.fill.gaps porting

On Apr 15, 2017 3:05 PM, "Benjamin Ducke" wrote: > > On 15/04/17 14:57, Markus Neteler wrote: ... > > Would it be possible to have larger pics here? I guess they come from > > Benjamin? > > No, the ones I submitted are really tiny. A pity... > The new LiDAR images are much

Re: [GRASS-dev] r.fill.gaps porting

On 15/04/17 14:57, Markus Neteler wrote: > > On Apr 15, 2017 2:52 PM, "Vaclav Petras" > wrote: >> >> On Sat, Apr 15, 2017 at 8:03 AM, Markus Neteler > wrote: >> > >> > > it is nice to see porting

Re: [GRASS-dev] r.fill.gaps porting

On Sat, Apr 15, 2017 at 8:57 AM, Markus Neteler wrote: > > These are 250x232, > > Would it be possible to have larger pics here? I guess they come from > Benjamin? > There are two next to each other, so the combined width is 500 which is almost our max for display (600).

Re: [GRASS-dev] r.fill.gaps porting

On Sat, Apr 15, 2017 at 7:51 AM, Maris Nartiss wrote: > As you added an example with LiDAR data - it is too large. Reduce its > size as default module help tab is much more narrow. > Maris, we agreed with Markus that the problem is in wxPython GUI versus submitting

Re: [GRASS-dev] r.fill.gaps porting

On Apr 15, 2017 2:52 PM, "Vaclav Petras" wrote: > > On Sat, Apr 15, 2017 at 8:03 AM, Markus Neteler wrote: > > > > > it is nice to see porting of old addons. > > > As you added an example with LiDAR data - it is too large. Reduce its > > > size as default

Re: [GRASS-dev] r.fill.gaps porting

On Sat, Apr 15, 2017 at 8:03 AM, Markus Neteler wrote: > > > it is nice to see porting of old addons. > > As you added an example with LiDAR data - it is too large. Reduce its > > size as default module help tab is much more narrow. > > The HTML code currently is this: > >

Re: [GRASS-dev] r.fill.gaps porting

Hi, Regarding the the smoothing, the description states: "Flags: [..] -p Preserve original cell values By default original values are smoothed" The first paragraph under "DESCRIPTION" says: "Alternatively, setting the -p flag will preserve the original cell values." Is that not

Re: [GRASS-dev] r.fill.gaps porting

On Apr 15, 2017 1:51 PM, "Maris Nartiss" wrote: > > Hello, > it is nice to see porting of old addons. > As you added an example with LiDAR data - it is too large. Reduce its > size as default module help tab is much more narrow. The HTML code currently is this: Please

[GRASS-dev] r.fill.gaps porting

Hello, it is nice to see porting of old addons. As you added an example with LiDAR data - it is too large. Reduce its size as default module help tab is much more narrow. A bigger problem is the modules description - as I was checking the output of module, it is reinterpolating all values instead