[GRASS-dev] [GRASS GIS] #3115: v.kriging: segfault if a parameter is not set

GRASS GIS trac at osgeo.org
Wed Oct 5 01:07:00 PDT 2016


#3115: v.kriging: segfault if a parameter is not set
-------------------------+-------------------------------------------------
  Reporter:  mlennert    |      Owner:  grass-dev@…
      Type:  defect      |     Status:  new
  Priority:  normal      |  Milestone:  7.0.6
 Component:  Addons      |    Version:  unspecified
Resolution:              |   Keywords:  v.kriging required parameter
       CPU:              |  segfault
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by mlennert):

 Response from Eva on the ML:

 On 04/10/16 22:00, Eva Stopková wrote:
 > 2016-08-04 15:42 GMT+02:00 GRASS GIS <trac at osgeo.org
 > <mailto:trac at osgeo.org>>:
 >
 >     #3115: v.kriging: segfault if a parameter is not set
 >
 -------------------------------------------------+-------------------------
 >      Reporter:  mlennert                             |      Owner:
 >     grass-dev@…
 >          Type:  defect                               |     Status:  new
 >      Priority:  normal                               |  Milestone:
 7.0.5
 >     Component:  Addons                               |    Version:
 >     unspecified
 >      Keywords:  v.kriging required parameter         |        CPU:
 >     Unspecified
 >       segfault                                       |
 >      Platform:  Unspecified                          |
 >
 -------------------------------------------------+-------------------------
 >      In the v.kriging addon, when I only provide the parameters marked
 as
 >      required (+ the -2 flag for 2D interpolation) I get the following:
 >
 >
 >      {{{
 >      v.extract elev_lid792_randpts out=elev_lid792_selected random=500
 --o
 >      v.kriging -2 input=elev_lid792_selected at user1 phase=initial
 >     icolumn=value
 >      WARNING: Not recommended to process for sparse or spatially
 >     heterogeneous
 >               data. The result can be inaccurate - trying to solve
 asap...
 >      Reading coordinates...
 >      Segmentation fault
 >      }}}
 >
 >      I have to add the report parameter for it to work:
 >
 >
 >      {{{
 >      v.kriging -2 input=elev_lid792_selected at user1 phase=initial
 >     icolumn=value
 >      report=report.txt
 >      }}}
 >
 >
 > I have fixed the bug like this: if the report name is missing, just
 > initial phase (preliminary experimental variogram computation) is
 > performed and the user is asked to repeat it with non-empty report
 > parameter if he wish to continue with theoretical variogram and
 > interpolation.
 >
 >
 >      At this stage, two unasked-for files are in the same directory:
 >     dataE.dat
 >      and
 >      variogram_hz_tmp.txt.
 >
 >      Required parameters should be declared as such and not lead to a
 >     segfault.
 >      And any temporary files created during the run of the module should
 be
 >      erased at the end.
 >
 >
 > These temporary files are necessary, as they store settings and results
 > from previous phases to be available in current phase of interpolation.
 > And the process needs to be splitted into phases, because there is an
 > interaction with the user needed (theoretical parameters settings
 > according to experimental variogram). Unfortunatelly, this is not
 > possible to manage interactively during module performance.
 >
 > As these files are unasked-for indeed, I have added the information
 > about them into command output: If initial phase is successfully
 > accomplished, the user is warned not to erase temporary files
 > <dataE.dat> and <variogram_hz_tmp.txt>. They are deleted in middle
 > (final) phase automatically, but in previous module version, the user
 > had been informed just in case that they were missing accidentally.
 >

 Changes are in r69676.

 This sounds like a good solution. Thank you !

 Another option would be to split the module into three modules. That way
 for each phase you can clearly define the inputs and outputs. It might
 make it clearer for the user. On the other hand, I understand the
 reasoning behind one module for kriging...

 IMHO, this really calls for a GUI wrapper above the module (or modules)
 that makes the different calls, based on interactive input from the user.

 Moritz

 P.S. When responding to bug tickets, it is always better to do this within
 the bug tracker, including a reference to the changeset in svn, so that
 your responses are logged there.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/3115#comment:2>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list