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

[Vaclav Petras]

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 result in unsatisfactory output. Also note
> that the smoothing increases with the interpolation
> radius. For tiny holes in LiDAR data, try "distance=1"
> or "2". Of course, LiDAR data probably has different
> properties and does not need low-pass filtering
> like gradiometer data. So try "-p" to preserve the
> original values.
>
> An alternative would be to invert the behaviour of
> the module and assume "-p" by default.
>
> I don't work with LiDAR data myself, but I would very
> interested to know your results!
>


I've added a figure which shows the r.slope.aspect products from the
surface without and with -p. You can see that the smoothing gives
significantly different results and probably better ones. I had the same
experience in past when trying to patch result of r.neighbors with the
original raster. Perhaps using smaller distance as you say or greater power
would help, but I haven't tested that yet.

I managed to commit just the figure its caption. If somebody gets to it,
please extent the section.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Markus Neteler]

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 wxPython HTML renderer correctly sets height=100% and
> width=600px. I changed submitting guidelines in Trac. Now it is
> necessary to provide correct heights for all images that have a width
> parameter.

Ok thanks for the update.
Ideally all manual pages would be updated to the same standard.

Anyone good in regex? Otherwise I could try a semi-manual bulk editing.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

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 automatically should set also
height. Not according to HTML spec (proportional scaling is not
mandated). Thus wxPython HTML renderer correctly sets height=100% and
width=600px. I changed submitting guidelines in Trac. Now it is
necessary to provide correct heights for all images that have a width
parameter.

>> However,
>> "Submitting/Docs" seems to assume that "width="
>> _will_ be processed correctly. So maybe the
>> best "fix" would be to add a statement to the
>> Wiki that images should be resized with an
>> external graphics editor (to 600 pixels width
>> or less) before including them in HTML man pages.
>
> Please don't... See above for the motivation. For a few years we follow the
> new policy. Better fix/work around the bad wx HTML renderer than reverting
> to low image quality.
>
> Cheers,
> Markus
>

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Markus Neteler]

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 larger. They
> use the "width=" HMTL attribute, so they show
> up much smaller on screen than they actually
> are.

Yes, on purpose.

The idea is to have higher resolution images in the code while showing a
clickable standard 600px width in the HTML page.
With a click one sees the larger image which is then also usable for
presentations and such (not possible with 250px only).

> Supposedly, the wxPython HTML renderer
> does not apply "width=" correctly and does not
> resize the image on the fly.

Unfortunately... Maybe an extra trick is needed/possible for this limited
renderer.
I'd like to not give up on quality submissions.

> However,
> "Submitting/Docs" seems to assume that "width="
> _will_ be processed correctly. So maybe the
> best "fix" would be to add a statement to the
> Wiki that images should be resized with an
> external graphics editor (to 600 pixels width
> or less) before including them in HTML man pages.

Please don't... See above for the motivation. For a few years we follow the
new policy. Better fix/work around the bad wx HTML renderer than reverting
to low image quality.

Cheers,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Benjamin Ducke]

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 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:
>> >
>> >src="r_fill_gaps_02.png" alt="Gaps filled">
>>
>>
>> These are 250x232,
> 
> Would it be possible to have larger pics here? I guess they come from
> Benjamin?

No, the ones I submitted are really tiny.
The new LiDAR images are much larger. They
use the "width=" HMTL attribute, so they show
up much smaller on screen than they actually
are. Supposedly, the wxPython HTML renderer
does not apply "width=" correctly and does not
resize the image on the fly. However,
"Submitting/Docs" seems to assume that "width="
_will_ be processed correctly. So maybe the
best "fix" would be to add a statement to the
Wiki that images should be resized with an
external graphics editor (to 600 pixels width
or less) before including them in HTML man pages.

Cheers,

Ben

> 
>> so I assume you mean r_fill_gaps_lidar.png.
>>
>> > Please use the img code as per submitting docs style guide in trac.
>>
>> The current code is:
>>
>> 
>> 
>> 
>>
>> which is almost exactly the following from Submitting/Docs [1]:
> 
> Ah I see... I'm mostly on mobile currently due to traveling, hence no
> easy reading of commit msgs.
> 
>> 
>> 
>> 
>>
>> The submitting guide does not consider the wxPython GUI manual tab
> which doesn't understand more advanced HTML correctly. Please advise on
> the next steps.
> 
> Ok just ignore my comment :)
> 
> Markus
> 
>> Vaclav
>>
>> [1] https://trac.osgeo.org/grass/wiki/Submitting/Docs
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

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).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

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 guidelines. Please open a ticket if you are bothered by it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Markus Neteler]

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 module help tab is much more narrow.
> >
> > The HTML code currently is this:
> >
> >   
>
>
> These are 250x232,

Would it be possible to have larger pics here? I guess they come from
Benjamin?

> so I assume you mean r_fill_gaps_lidar.png.
>
> > Please use the img code as per submitting docs style guide in trac.
>
> The current code is:
>
> 
> 
> 
>
> which is almost exactly the following from Submitting/Docs [1]:

Ah I see... I'm mostly on mobile currently due to traveling, hence no easy
reading of commit msgs.

> 
> 
> 
>
> The submitting guide does not consider the wxPython GUI manual tab which
doesn't understand more advanced HTML correctly. Please advise on the next
steps.

Ok just ignore my comment :)

Markus

> Vaclav
>
> [1] https://trac.osgeo.org/grass/wiki/Submitting/Docs
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

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:
>
>   


These are 250x232, so I assume you mean r_fill_gaps_lidar.png.

> Please use the img code as per submitting docs style guide in trac.

The current code is:





which is almost exactly the following from Submitting/Docs [1]:





The submitting guide does not consider the wxPython GUI manual tab which
doesn't understand more advanced HTML correctly. Please advise on the next
steps.

Vaclav

[1] https://trac.osgeo.org/grass/wiki/Submitting/Docs
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Benjamin Ducke]

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 clear enough? If you want then I can add
a more prominent statement at the beginning of the
help page.

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 result in unsatisfactory output. Also note
that the smoothing increases with the interpolation
radius. For tiny holes in LiDAR data, try "distance=1"
or "2". Of course, LiDAR data probably has different
properties and does not need low-pass filtering
like gradiometer data. So try "-p" to preserve the
original values.

An alternative would be to invert the behaviour of
the module and assume "-p" by default.

I don't work with LiDAR data myself, but I would very
interested to know your results!

Best,

Ben


On 15/04/17 13:51, 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.
> A bigger problem is the modules description - as I was checking the
> output of module, it is reinterpolating all values instead of just
> filling gaps. Thus the result is smoothened instead of just being
> filled. This is in a sharp contrast to r.fill.nulls and thus should be
> stressed out.
> 
> Thanks for a good work!
> Māris.
> ___
> grass-dev mailing list
> grass-dev@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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Markus Neteler]

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 use the img code as per submitting docs style guide in trac.

> Thanks for a good work!

Yes, great!

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.fill.gaps porting

[Maris Nartiss]

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 of just
filling gaps. Thus the result is smoothened instead of just being
filled. This is in a sharp contrast to r.fill.nulls and thus should be
stressed out.

Thanks for a good work!
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev