[GRASS-dev] Re: another r.resamp.interp bug report

On Mar 18, 2008, at 4:06 PM, grass-user-request@lists.osgeo.org wrote:

Date: Tue, 18 Mar 2008 20:21:38 +0100
From: Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>
Subject: Re: [GRASS-user] r.in.xyz
To: Edmondo Elisei <edmondo.elisei@gmail.com>
Cc: grass-user@lists.osgeo.org
Message-ID: <1205868098.19886.19.camel@vertical>
Content-Type: text/plain

On Tue, 2008-03-18 at 17:02 +0100, Edmondo Elisei wrote:

5) r.bilinear syntax
r.bilinear input=subset output=subsetsurface --overwrite

For the second part of the test:

I am having trouble to resample with r.resamp.interp mode=bilinear. But
I think this has to do with the available values (I got only 6 points
imported)

In the manual one can read as well:

Note that for bilinear and bicubic interpolation, cells of the output
raster that cannot be bounded by the appropriate number of input cell
centers are set to null. This could occur due to the input cells being
outside the current region, being NULL or MASKed.

So, I suppose with a larger sample it shoud feasible.

Nikos,

I just ran into this today. I haven't done any interpolation in a few months, so I don't know when this bug crept in. I cannot get any decent maps out of r.resamp.interp. The bilinear and bicubic routines only produce NAN maps, and the nearest routine creates a map that is composed only of the input points.

v.surf.bspline hasn't worked in awhile and I'm getting sporadic crashes (more often than not) with v.surf.rst with no error message (except for a system one that the program has caused an error).

So for me today, the only interpolation routine that seems to work out of all the ones in the GRASS toolkit is v.surf.idw--one of the worst.

Michael

Michael - I have added an example from the book at the bottom of this page - please try it and let me know whether it works.
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/demo.txt

Please keep in mind that r.resample* is for reinterpolation of continuous data to a different resolution not for interpolation from scattered data (see the equations in the Appendix on what it does) (r.surf.idw is designed for scattered data input in raster format). You should convert your points from raster to vector points and use the v.surf* modules to interpolate.

I hope this helps and let me know if the examples don't work

Helena Mitasova
Associate Professor
Department of Marine, Earth
and Atmospheric Sciences
1125 Jordan Hall, Campus Box 8208
North Carolina State University
Raleigh NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

On Mar 19, 2008, at 12:30 AM, Michael Barton wrote:

On Mar 18, 2008, at 4:06 PM, grass-user-request@lists.osgeo.org wrote:

Date: Tue, 18 Mar 2008 20:21:38 +0100
From: Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>
Subject: Re: [GRASS-user] r.in.xyz
To: Edmondo Elisei <edmondo.elisei@gmail.com>
Cc: grass-user@lists.osgeo.org
Message-ID: <1205868098.19886.19.camel@vertical>
Content-Type: text/plain

On Tue, 2008-03-18 at 17:02 +0100, Edmondo Elisei wrote:

5) r.bilinear syntax
r.bilinear input=subset output=subsetsurface --overwrite

For the second part of the test:

I am having trouble to resample with r.resamp.interp mode=bilinear. But
I think this has to do with the available values (I got only 6 points
imported)

In the manual one can read as well:

Note that for bilinear and bicubic interpolation, cells of the output
raster that cannot be bounded by the appropriate number of input cell
centers are set to null. This could occur due to the input cells being
outside the current region, being NULL or MASKed.

So, I suppose with a larger sample it shoud feasible.

Nikos,

I just ran into this today. I haven't done any interpolation in a few months, so I don't know when this bug crept in. I cannot get any decent maps out of r.resamp.interp. The bilinear and bicubic routines only produce NAN maps, and the nearest routine creates a map that is composed only of the input points.

v.surf.bspline hasn't worked in awhile and I'm getting sporadic crashes (more often than not) with v.surf.rst with no error message (except for a system one that the program has caused an error).

So for me today, the only interpolation routine that seems to work out of all the ones in the GRASS toolkit is v.surf.idw--one of the worst.

Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Mar 18, 2008, at 9:39 PM, Helena Mitasova wrote:

Michael - I have added an example from the book at the bottom of this page - please try it and let me know whether it works.
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/demo.txt

Please keep in mind that r.resample* is for reinterpolation of continuous data to a different resolution not for interpolation from scattered data (see the equations in the Appendix on what it does) (r.surf.idw is designed for scattered data input in raster format). You should convert your points from raster to vector points and use the v.surf* modules to interpolate.

I hope this helps and let me know if the examples don't work

Thanks Helena. The issue that I ran into today (embarrassingly with my class) is that of the v.surf.*modules, v.surf.bspline does not work (I reported this sometime back), v.surf.rst crashes and brings down the entire GUI (this is new), leaving only v.surf.idw as the only functional interpolation routine in todays SVN trunk.

Michael

On Mar 19, 2008, at 12:49 AM, Michael Barton wrote:

On Mar 18, 2008, at 9:39 PM, Helena Mitasova wrote:

Michael - I have added an example from the book at the bottom of this page - please try it and let me know whether it works.
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/demo.txt

Please keep in mind that r.resample* is for reinterpolation of continuous data to a different resolution not for interpolation from scattered data (see the equations in the Appendix on what it does) (r.surf.idw is designed for scattered data input in raster format). You should convert your points from raster to vector points and use the v.surf* modules to interpolate.

I hope this helps and let me know if the examples don't work

Thanks Helena. The issue that I ran into today (embarrassingly with my class) is that of the v.surf.*modules, v.surf.bspline does not work (I reported this sometime back), v.surf.rst crashes and brings down the entire GUI (this is new), leaving only v.surf.idw as the only functional interpolation routine in todays SVN trunk.

nothing has changed in rst except for some message standardization 4 months ago and build cleanup (makefile) by glynn 6 months ago.
I am wondering whether something in GUI has changed that conflicts with what rst is doing (or rst is doing something that the modified GUI does not like ) - perhaps there is some computation before G_parser is called - would that crash it?
It is 1am now so I need to go but I can look at it tomorrow if I can get some hints on what the problem may be.
I never run it from GUI so it might have been there for a while.

Helena

Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Mar 18, 2008, at 10:09 PM, Helena Mitasova wrote:

On Mar 19, 2008, at 12:49 AM, Michael Barton wrote:

On Mar 18, 2008, at 9:39 PM, Helena Mitasova wrote:

Michael - I have added an example from the book at the bottom of this page - please try it and let me know whether it works.
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/demo.txt

Please keep in mind that r.resample* is for reinterpolation of continuous data to a different resolution not for interpolation from scattered data (see the equations in the Appendix on what it does) (r.surf.idw is designed for scattered data input in raster format). You should convert your points from raster to vector points and use the v.surf* modules to interpolate.

I hope this helps and let me know if the examples don't work

Thanks Helena. The issue that I ran into today (embarrassingly with my class) is that of the v.surf.*modules, v.surf.bspline does not work (I reported this sometime back), v.surf.rst crashes and brings down the entire GUI (this is new), leaving only v.surf.idw as the only functional interpolation routine in todays SVN trunk.

nothing has changed in rst except for some message standardization 4 months ago and build cleanup (makefile) by glynn 6 months ago.
I am wondering whether something in GUI has changed that conflicts with what rst is doing (or rst is doing something that the modified GUI does not like ) - perhaps there is some computation before G_parser is called - would that crash it?
It is 1am now so I need to go but I can look at it tomorrow if I can get some hints on what the problem may be.
I never run it from GUI so it might have been there for a while.

Helena

Thanks again Helena. In fact, I haven't need to do interpolation for at least 6 months and so it might well have been there for awhile. I'm doing further testing too.

Michael

Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

Can somebody please verify that v.surf.rst is crashing the GUI in the latest SVN trunk?
It works fine for me in the August 2007 version on Mac and February 18 version on linux.
We don't want to get this bug into the release,

thanks,

Helena

On Mar 19, 2008, at 1:26 AM, Michael Barton wrote:

On Mar 18, 2008, at 10:09 PM, Helena Mitasova wrote:

On Mar 19, 2008, at 12:49 AM, Michael Barton wrote:

On Mar 18, 2008, at 9:39 PM, Helena Mitasova wrote:

Michael - I have added an example from the book at the bottom of this page - please try it and let me know whether it works.
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/demo.txt

Please keep in mind that r.resample* is for reinterpolation of continuous data to a different resolution not for interpolation from scattered data (see the equations in the Appendix on what it does) (r.surf.idw is designed for scattered data input in raster format). You should convert your points from raster to vector points and use the v.surf* modules to interpolate.

I hope this helps and let me know if the examples don't work

Thanks Helena. The issue that I ran into today (embarrassingly with my class) is that of the v.surf.*modules, v.surf.bspline does not work (I reported this sometime back), v.surf.rst crashes and brings down the entire GUI (this is new), leaving only v.surf.idw as the only functional interpolation routine in todays SVN trunk.

nothing has changed in rst except for some message standardization 4 months ago and build cleanup (makefile) by glynn 6 months ago.
I am wondering whether something in GUI has changed that conflicts with what rst is doing (or rst is doing something that the modified GUI does not like ) - perhaps there is some computation before G_parser is called - would that crash it?
It is 1am now so I need to go but I can look at it tomorrow if I can get some hints on what the problem may be.
I never run it from GUI so it might have been there for a while.

Helena

Thanks again Helena. In fact, I haven't need to do interpolation for at least 6 months and so it might well have been there for awhile. I'm doing further testing too.

Michael

Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Markus,

thanks for getting back to me on this,

v.surf.rst runs fine from the tcltk gui, it but has several problems in wxpython gui
(this is for today's update of grass65):

1. It is really hard to find where to put the name of the main output "elevation"
  - it is not under tab "outputs" but it is under tab "optional" which has several inputs
that you actually must define if you don't want to end up interpolating category
numbers. The tab optional isn't visible, so you need to click on the arrow to get to it.
I think the elevation should be under outputs

2. I was unable to change the layer number - it was stuck at 1 (this may be problem
with my installation or I am not clicking on it the right way?, typing it in, deleting it did not
work either), so there was no way
to interpolate the z-coordinate. I think that the layer number should be under
input tab (required) - it is in fact required or you will end up interpolating cats.
I would put column name there too, it is required for default layer 1, otherwise cats
are interpolated. I do not find these defaults convenient but this was the consensus
by others when s.surf.rst was updated to v.surf.rst.

Otherwise the new GUI is really, really nice - I hope we will be able to switch to it
for the fall 2009 classes.

Helena

P.S. Any chance for changing default layer to 0 at least in grass7,
to make it possible to run just v.surf.rst mypoints elev=myelev ?
Without defining layer, it is set to 1 and category number is interpolated
by default if column is not defined - particularly unpleasant surprise
after running a longer computation. Layer number and column name can then be
under optional. I can make the change in grass7 if there are no objections
to see whether it will cause any problems.

P.P.S. Any chance for getting winGRASS under Express install in OSGeo4W?
Our IT did not think the current OSGeo4W design was very good for installing GRASS.
On the other hand, Marco's installer for GRASS6.3 has been a great success here.

On Mar 7, 2009, at 3:22 PM, Markus Neteler wrote:

Helena,

still the case?

Markus

On Wed, Mar 19, 2008 at 6:48 PM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

Can somebody please verify that v.surf.rst is crashing the GUI in the latest
SVN trunk?
It works fine for me in the August 2007 version on Mac and February 18
version on linux.
We don't want to get this bug into the release,

thanks,

Helena

Helena,

On Sun, Mar 8, 2009 at 3:37 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

Markus,

thanks for getting back to me on this,

v.surf.rst runs fine from the tcltk gui, it but has several problems in
wxpython gui
(this is for today's update of grass65):

1. It is really hard to find where to put the name of the main output
"elevation"
- it is not under tab "outputs" but it is under tab "optional" which has
several inputs
that you actually must define if you don't want to end up interpolating
category
numbers. The tab optional isn't visible, so you need to click on the arrow
to get to it.
I think the elevation should be under outputs

I agree with you that it is hard to find (see screenshot attached).
The reason is that in
vector/v.surf.rst/main.c
the entry
parm.elev->guisection = _("Output_options");
is not defined. But see for related WX bug below...

Additionally:
In the Tcl GUI you get the parameter name shown, too. Would it be
possible to add that to the WX GUI, too? see attached screenshot
for what I mean.

Another suggestion: make the WX tabs consume less horizontal space
to see one more tab in the default width.

2. I was unable to change the layer number - it was stuck at 1

I just see that the description says:
    parm.field->description =
        _("Field value. If set to 0, z coordinates are used. (3D vector only)");

will take out "Field" as it is called "layer".

(this may be problem with my installation or I am not clicking on it the
right way?, typing it in, deleting it did not work either), so there was no way
to interpolate the z-coordinate.

I also don't see it. Seems to disappear somewhere. in the
Tcl GUI it's present.
I think that there is a bug for all parameters not having
guisection defined. They should go into the "Optional" tab
but they don't (they disappear apparently).

I think that the layer number should be under
input tab (required) - it is in fact required or you will end up
interpolating cats.

Then we have to make it required in main.c
The wx GUI is generated from what's defined there.

I would put column name there too, it is required for default layer 1,
otherwise cats
are interpolated. I do not find these defaults convenient but this was the
consensus by others when s.surf.rst was updated to v.surf.rst.

Again, it depends on parm->guisection...

Otherwise the new GUI is really, really nice - I hope we will be able to
switch to it for the fall 2009 classes.

Helena

P.S. Any chance for changing default layer to 0 at least in grass7,
to make it possible to run just v.surf.rst mypoints elev=myelev ?

Why not - in 7 we are allowed to change the defaults.
Just submit the change (please also check the html docs for update).

Without defining layer, it is set to 1 and category number is interpolated
by default if column is not defined - particularly unpleasant surprise
after running a longer computation. Layer number and column name can then be
under optional. I can make the change in grass7 if there are no objections
to see whether it will cause any problems.

I don't see problems.

P.P.S. Any chance for getting winGRASS under Express install in OSGeo4W?
Our IT did not think the current OSGeo4W design was very good for installing
GRASS.

It will go into Express install in OSGeo4W once we have a successful run
with the new GUI. Currently we are in a deadlock: the actual packager
doesn't want to prepare candidates any more before the final release and
we won't do the final release before a successful candidate...
We do need to find someone who packages winGRASS for OSGeo4W.

On the other hand, Marco's installer for GRASS6.3 has been a great success
here.

Yes - unfortunately he doesn't seem to continue. Volunteer needed...

Markus

(attachments)

v.surf.rst_tcl_wx.jpg

On Sun, Mar 8, 2009 at 7:05 AM, Markus Neteler <neteler@osgeo.org> wrote:
...

I also don't see it. Seems to disappear somewhere. in the
Tcl GUI it's present.
I think that there is a bug for all parameters not having
guisection defined. They should go into the "Optional" tab
but they don't (they disappear apparently).

Is it possible that (currently) none of the parameters is
visible which are defined via
G_define_standard_option()
? (since there is not default guisection)

Markus

Hi,

2009/3/8 Helena Mitasova <hmitaso@unity.ncsu.edu>:

1. It is really hard to find where to put the name of the main output
"elevation"
- it is not under tab "outputs" but it is under tab "optional" which has
several inputs
that you actually must define if you don't want to end up interpolating
category
numbers. The tab optional isn't visible, so you need to click on the arrow
to get to it.
I think the elevation should be under outputs

indeed, I am trying to keep all parameters in four tabs (which are
visible by default). I don't feel familiar with v.surf.rst. Could you
suggest reordering parameters to less tabs?

2. I was unable to change the layer number - it was stuck at 1 (this may be
problem
with my installation or I am not clicking on it the right way?, typing it
in, deleting it did not
work either), so there was no way
to interpolate the z-coordinate. I think that the layer number should be

It was a bug, fixed in r36250 (devbr6) and r36251 (relbr64).

P.S. Any chance for changing default layer to 0 at least in grass7,
to make it possible to run just v.surf.rst mypoints elev=myelev ?
Without defining layer, it is set to 1 and category number is interpolated
by default if column is not defined - particularly unpleasant surprise
after running a longer computation. Layer number and column name can then be
under optional. I can make the change in grass7 if there are no objections
to see whether it will cause any problems.

I would suggest to replace in all modules which uses 'layer=0' with
appropriate flag.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Mar 8, 2009, at 9:07 AM, Martin Landa wrote:

Hi,

2009/3/8 Helena Mitasova <hmitaso@unity.ncsu.edu>:

1. It is really hard to find where to put the name of the main output
"elevation"
- it is not under tab "outputs" but it is under tab "optional" which has
several inputs
that you actually must define if you don't want to end up interpolating
category
numbers. The tab optional isn't visible, so you need to click on the arrow
to get to it.
I think the elevation should be under outputs

indeed, I am trying to keep all parameters in four tabs (which are
visible by default). I don't feel familiar with v.surf.rst. Could you
suggest reordering parameters to less tabs?

yes

Anisotropy can be merged into Settings (better name for that tab may be Parameters)
Also Analysis can be merged into Outputs

so it could be
Inputs Outputs Parameters

and Markus is right - guisection is missing for elev, it should be added here

189 parm.elev->description = _("Output surface raster map (elevation)");
parm.elev->guisection = _("Output_options");

and for maskmap as well (that should be under Inputs tab)

If you could change this it would be great (I won't have time until weekend to
do something about it)

thanks a lot

Helena

P.S. using -z instead of layer=0 is a great idea, I will look into it

2. I was unable to change the layer number - it was stuck at 1 (this may be
problem
with my installation or I am not clicking on it the right way?, typing it
in, deleting it did not
work either), so there was no way
to interpolate the z-coordinate. I think that the layer number should be

It was a bug, fixed in r36250 (devbr6) and r36251 (relbr64).

P.S. Any chance for changing default layer to 0 at least in grass7,
to make it possible to run just v.surf.rst mypoints elev=myelev ?
Without defining layer, it is set to 1 and category number is interpolated
by default if column is not defined - particularly unpleasant surprise
after running a longer computation. Layer number and column name can then be
under optional. I can make the change in grass7 if there are no objections
to see whether it will cause any problems.

I would suggest to replace in all modules which uses 'layer=0' with
appropriate flag.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Hi,

2009/3/13 Helena Mitasova <hmitaso@unity.ncsu.edu>:

[...]

Inputs Outputs Parameters

and Markus is right - guisection is missing for elev, it should be added
here

189 parm.elev->description = _("Output surface raster map (elevation)");
parm.elev->guisection = _("Output_options");

and for maskmap as well (that should be under Inputs tab)

If you could change this it would be great (I won't have time until weekend
to
do something about it)

done in GRASS 7 (r36353). In no objections I will backported it to
devbr6/relbr64.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Fri, Mar 13, 2009 at 8:55 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2009/3/13 Helena Mitasova <hmitaso@unity.ncsu.edu>:

[...]

Inputs Outputs Parameters

and Markus is right - guisection is missing for elev, it should be added
here

189 parm.elev->description = _("Output surface raster map (elevation)");
parm.elev->guisection = _("Output_options");

and for maskmap as well (that should be under Inputs tab)

If you could change this it would be great (I won't have time until weekend
to
do something about it)

done in GRASS 7 (r36353). In no objections I will backported it to
devbr6/relbr64.

Great job, Martin! Looks much better now.

Thanks also for the "clean" Cmd> button.

Markus

2009/3/13 Markus Neteler <neteler@osgeo.org>:

[...]

done in GRASS 7 (r36353). In no objections I will backported it to
devbr6/relbr64.

backported in r36358 (devbr6) and r36359 (relbr64).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Tue, 2008-03-18 at 21:49 -0700, Michael Barton wrote:

On Mar 18, 2008, at 9:39 PM, Helena Mitasova wrote:

> Michael - I have added an example from the book at the bottom of
> this page - please try it and let me know whether it works.
> http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/
> ncexternal/demo.txt
>
> Please keep in mind that r.resample* is for reinterpolation of
> continuous data to a different resolution not for interpolation
> from scattered data (see the equations in the Appendix on what it
> does) (r.surf.idw is designed for scattered data input in raster
> format). You should convert your points from raster to vector
> points and use the v.surf* modules to interpolate.
>
> I hope this helps and let me know if the examples don't work

Thanks. It's clear now.

>

Thanks Helena. The issue that I ran into today (embarrassingly with
my class) is that of the v.surf.*modules, v.surf.bspline does not
work (I reported this sometime back), v.surf.rst crashes and brings
down the entire GUI (this is new), leaving only v.surf.idw as the
only functional interpolation routine in todays SVN trunk.

Michael

Michael, just out of curiousity: is your initial input data vector
(points) or raster (scattered pixels)?

Thank you in advance,

Nikos