[GRASS-dev] Re: [GRASS GIS] #522: NVIZ fails to start

[GRASS GIS]

#522: NVIZ fails to start
--+-
  Reporter:  ewcgrass |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  unspecified  
Resolution:  invalid  |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by cmbarton):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 Glad that you were able to work out the source of the problem. Closing
 this ticket.

 Michael

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

[Glynn Clements]

Michael Barton wrote:

> >> I have been investigating the r.mfilter.fp function with a relatively
> >> large raster file. My poor 6.3.0 version (on a x64bits - Poseidon
> >> (ubuntu) distribution) of this binary keeps sending me a deadly
> >> "segmentation fault".
> >> I would like to know if this is a known issue? If yes any  
> >> suggestion on
> >> how to solve it?
> >
> > I can't find any record of any bugs being fixed in r.mfilter.fp since
> > it was created, so it doesn't look like a known issue.
> >
> > Can you provide a recipe to reproduce this using only the sample
> > datasets or generated data?
> >
> > -- 
> > Glynn Clements 
> 
> Glynn, others,
> 
> Assuming that this report turns out to be not a problem, is there any  
> reason not to simply replace r.mfilter with r.mfilter.fp?

Only the fact that it's not 100% backwards compatible, although I have
no idea whether anyone will actually want the old behaviour.

Apart from the use of integers, r.mfilter reads nulls as zero, while
r.mfilter.fp reads nulls as null and propagates them (i.e. the result
cell will be null if any cell in the moving window is null).

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

[Markus Neteler]

On Thu, Mar 12, 2009 at 11:45 AM, Glynn Clements
 wrote:
> Only the fact that it's not 100% backwards compatible, although I have
> no idea whether anyone will actually want the old behaviour.

This might be unlikely.

> Apart from the use of integers, r.mfilter reads nulls as zero, while
> r.mfilter.fp reads nulls as null and propagates them (i.e. the result
> cell will be null if any cell in the moving window is null).

Could we have the same mechanism as in r.series (-n flag)?

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

[GRASS-dev] [GRASS GIS] #526: g.mapsets error in wxpython

[GRASS GIS]

#526: g.mapsets error in wxpython
--+-
 Reporter:  cnielsen  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  major |   Milestone:  7.0.0
Component:  default   | Version:  svn-trunk
 Keywords:|Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-
 I get an error when trying to add a map (or open various module dialogs)
 to the display in wxpython. (Under Vista mingw/msys)

 Traceback (most recent call last):
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\wxgui_utils.py", line 903, in OnActivateLayer

 self.PropertiesDialog (layer)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\wxgui_utils.py", line 839, in PropertiesDialog

 parentframe=self)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\menuform.py", line 1772, in ParseCommand

 get_dcmd=get_dcmd, layer=layer)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\menuform.py", line 619, in __init__

 mainFrame=self)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\menuform.py", line 1187, in __init__

 multiple=multiple, mapsets=mapsets)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\gselect.py", line 55, in __init__

 self.tcp.GetElementList(type, mapsets, exceptOf)
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\gselect.py", line 161, in GetElementList

 mapsets = utils.ListOfMapsets()
   File "C:\MinGW\msys\local\grass-7.0.svn\etc\wxpython\gui_m
 odules\utils.py", line 226, in ListOfMapsets

 message = _('Unable to get list of accessible mapsets.'))
 gui_modules.gcmd
 .
 CmdError

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.type.sh question - important for 6.4 release

[Michael Barton]

On Mar 11, 2009, at 12:10 PM, Glynn Clements wrote:



The way that we normally make shell scripts work on Windows is to
provide a .bat file which explicitly invokes the script via  
$GRASS_SH.


On Windows, the $GISBASE/bin directory will contain a .bat file for
each script in the $GISBASE/scripts directory. These are created  
using

the scripts/windows_launch.bat file as a template.

It may suffice to add $GISBASE/etc/gui/scripts/v.type.sh.bat. If  
that

doesn't work, add an "if windows ..." case to gis.m's "execute"
function, which invokes the script via $env(GRASS_SH).

--  
Glynn Clements 


This sounds good. Two questions.

1) How can we get the *.bat files to be generated for files in the
$GISBASE/ext/gui/scripts folder?


For the scripts in the scripts directory, this is done via the
following rule from Script.make:

$(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat
	sed -e "s#SCRIPT_NAME#$(PGM)#" $(MODULE_TOPDIR)/scripts/ 
windows_launch.bat > $@


For the gui/scripts, the above rule can be generalised to a pattern  
rule:


$(GISBASE)/etc/gui/scripts/%.bat: $(MODULE_TOPDIR)/scripts/ 
windows_launch.bat
	sed -e "s#SCRIPT_NAME#$*#" $(MODULE_TOPDIR)/scripts/ 
windows_launch.bat > $@


You then need to "make" the relevant .bat files with e.g.:

	for file in *.* ; do $(MAKE) $(GISBASE)/etc/gui/scripts/$ 
$file.bat ; done


2) Can v.type.sh.bat be called by just specifying v.type.sh? Or do  
you

need to fully specify the *.bat extension?


Just using the base name seems to work for everything else, although I
can't exclude the possibility that Tcl behaves differently depending
upon whether a full path is used (it's actually Tcl which tries the
.exe and .bat suffixes; it doesn't use Windows' ShellExecute()).

--
Glynn Clements 


If someone who knows the build system well can make the changes Glynn  
recommended to Script.make, we can test to see if that does the trick.  
If not, I can change try to conditionalize the TclTk call for windows  
to find v.type.sh.bat.


(related question, is such a name permitted for Windows XP and Vista?)

Michael



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

Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

[Michael Barton]

On Mar 12, 2009, at 3:45 AM, Glynn Clements wrote:



Michael Barton wrote:

I have been investigating the r.mfilter.fp function with a  
relatively

large raster file. My poor 6.3.0 version (on a x64bits - Poseidon
(ubuntu) distribution) of this binary keeps sending me a deadly
"segmentation fault".
I would like to know if this is a known issue? If yes any
suggestion on
how to solve it?


I can't find any record of any bugs being fixed in r.mfilter.fp  
since

it was created, so it doesn't look like a known issue.

Can you provide a recipe to reproduce this using only the sample
datasets or generated data?

--
Glynn Clements 


Glynn, others,

Assuming that this report turns out to be not a problem, is there any
reason not to simply replace r.mfilter with r.mfilter.fp?


Only the fact that it's not 100% backwards compatible, although I have
no idea whether anyone will actually want the old behaviour.

Apart from the use of integers, r.mfilter reads nulls as zero, while
r.mfilter.fp reads nulls as null and propagates them (i.e. the result
cell will be null if any cell in the moving window is null).

--
Glynn Clements 


Following up on this, are the rest of the group willing to replace the  
old r.mfilter code with code from the new r.mfilter.fp?


Michael

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

[GRASS-dev] Re: [GRASS GIS] #399: Added "backlink" functionality to r.walk, r.cost & r.drain

[GRASS GIS]

#399: Added "backlink" functionality to r.walk, r.cost & r.drain
--+-
  Reporter:  cnielsen |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by cnielsen):

 Fixed some spacing issues, patches now only contain "hunks" of genuine
 changes and not extra spaces.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #399: Added "backlink" functionality to r.walk, r.cost & r.drain

[GRASS GIS]

#399: Added "backlink" functionality to r.walk, r.cost & r.drain
--+-
  Reporter:  cnielsen |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by dylan):

 Just re-compiled GRASS with Colin's recent patches to r.cost, r.drain, and
 r.walk. Compiles fine against develbranch_6 on linux, with visibly
 different results. Using the output direction update to r.cost/r.drain
 does not appear to differ much from the original implementation. The
 results from r.walk/r.drain using the output direction patch results in
 considerably differences-- that appear to be non-optimal in this terrain.
 Code and resulting output posted here:

 http://casoilresource.lawr.ucdavis.edu/drupal/node/544#comment-948

 Thanks for the work on these modules. I wonder if using more than the
 cardinal directions would result in a more realistic "direction map".

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #399: Added "backlink" functionality to r.walk, r.cost & r.drain

[GRASS GIS]

#399: Added "backlink" functionality to r.walk, r.cost & r.drain
--+-
  Reporter:  cnielsen |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by dylan):

 Actually, after looking at the new output from r.walk/r.drain, the
 linearity of the shortest cost path made me think that the path was
 somehow non-optimal. It is actually much shorter (by 1.2km), and probably
 not impossible in this terrain.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.type.sh question - important for 6.4 release

[Glynn Clements]

Michael Barton wrote:

> >> 1) How can we get the *.bat files to be generated for files in the
> >> $GISBASE/ext/gui/scripts folder?
> >
> > For the scripts in the scripts directory, this is done via the
> > following rule from Script.make:
> >
> > $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat
> > sed -e "s#SCRIPT_NAME#$(PGM)#" 
> > $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@
> >
> > For the gui/scripts, the above rule can be generalised to a pattern  
> > rule:
> >
> > $(GISBASE)/etc/gui/scripts/%.bat: 
> > $(MODULE_TOPDIR)/scripts/windows_launch.bat
> > sed -e "s#SCRIPT_NAME#$*#" $(MODULE_TOPDIR)/scripts/windows_launch.bat 
> > > $@
> >
> > You then need to "make" the relevant .bat files with e.g.:
> >
> > for file in *.* ; do $(MAKE) $(GISBASE)/etc/gui/scripts/$$file.bat ; 
> > done

> If someone who knows the build system well can make the changes Glynn  
> recommended to Script.make, we can test to see if that does the trick.  

The changes should be made in gui/scripts/Makefile, not Script.make.

> If not, I can change try to conditionalize the TclTk call for windows  
> to find v.type.sh.bat.
> 
> (related question, is such a name permitted for Windows XP and Vista?)

AFAIK, there is no restriction on having dots within a filename. Only
the final extension (the part after the last dot) is significant to
Windows.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

[Glynn Clements]

Markus Neteler wrote:

> > Only the fact that it's not 100% backwards compatible, although I have
> > no idea whether anyone will actually want the old behaviour.
> 
> This might be unlikely.
> 
> > Apart from the use of integers, r.mfilter reads nulls as zero, while
> > r.mfilter.fp reads nulls as null and propagates them (i.e. the result
> > cell will be null if any cell in the moving window is null).
> 
> Could we have the same mechanism as in r.series (-n flag)?

We can add a flag to make it interpret null as zero.

Note that there's already the special treatment used if the divisor is
zero.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #399: Added "backlink" functionality to r.walk, r.cost & r.drain

[GRASS GIS]

#399: Added "backlink" functionality to r.walk, r.cost & r.drain
--+-
  Reporter:  cnielsen |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by cnielsen):

 Thanks for the testing and the how-to Dylan. I should emphasize that the
 changes I made only record the directions taken by the original cost
 accumulation algorithm. These means that I have not (well only a slight
 change to fix a mathematical error) changed how r.cost or r.walk
 calculates paths, only how those same paths are recorded and then turned
 into paths using r.drain.

 The clearest way I can put it is to think of the knight's move. With the
 old modules, r.drain had no way to tell if the cost surface was created
 with or without knight's move. Instead it just followed a water drop
 "drain" through the map only looking at 8 neighbours. Now it uses the
 direction surface to remember what the cost accumulation algorithm did and
 recreates that path.

 Therefore the cardinal directions are necessary (and precisely sufficient)
 since they record either eight directions, or for knight's move sixteen
 directions, based on the original moves... does that make sense?

 Also patches for grass_trunk aka grass70 are ready for testing (they work
 for me).

 -Colin

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-SVN] r36342 - grass/trunk/raster/r.los

[Markus Neteler]

On Thu, Mar 12, 2009 at 12:33 PM,   wrote:
> Author: glynn
> Date: 2009-03-12 07:33:40 -0400 (Thu, 12 Mar 2009)
> New Revision: 36342
>
> Modified:
>   grass/trunk/raster/r.los/main.c
>   grass/trunk/raster/r.los/point.h
> Log:
> Fix compilation error due to r36161/r36181; 7.0 doesn't abuse the preprocessor

A backport candidate?

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

[GRASS-dev] Re: [GRASS GIS] #526: g.mapsets error in wxpython

[GRASS GIS]

#526: g.mapsets error in wxpython
--+-
  Reporter:  cnielsen |   Owner:  martinl  
  Type:  defect   |  Status:  assigned 
  Priority:  major|   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  MSWindows Vista  | Cpu:  x86-32   
--+-
Changes (by martinl):

  * status:  new => assigned
  * owner:  grass-dev@lists.osgeo.org => martinl
 * cc: grass-dev@lists.osgeo.org (added)

Comment:

 Hopefully fixed in r36345.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #525: error: ‘wxGCDC’ has not been declared

[GRASS GIS]

#525: error: ‘wxGCDC’ has not been declared
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-develbranch6 
Resolution:  fixed|Keywords:  vdigit   
  Platform:  Linux| Cpu:  x86-64   
--+-
Changes (by martinl):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Has been fixed in all active branches.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [osgeo4w] #37: grass: wxpython gui issues

[OSGeo4W]

#37: grass: wxpython gui issues
---+
Reporter:  jachym  |Owner:  osgeo4w-...@lists.osgeo.org
Type:  defect  |   Status:  new
Priority:  major   |Component:  Package
 Version:  |   Resolution: 
Keywords:  GRASS   |  
---+
Comment (by martinl):

 Replying to [comment:28 hamish]:
 > but "Search in description" doesn't seem to work.

 hopefully fixed in r36346.

 > Should the [Browse EPSG Codes] button there be renamed [Search] ?
 > clicking that refreshes the list, but it is still at the top.
 > or do I just press enter in the search text entry box? (does nothing)

 OK, it was confusing. The button renamed to "Reload EPGS codes".

 Martin

-- 
Ticket URL: 
OSGeo4W 
OSGeo4W is the Windows installer for the OSGeo stack.___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #519: osgeo4w build

[Markus Neteler]

On Sun, Mar 8, 2009 at 10:23 PM, GRASS GIS  wrote:
> #519: osgeo4w build
> --+-
>  Reporter:  jef      |       Owner:  grass-...@lists.osgeo.org
>      Type:  task     |      Status:  new
>  Priority:  major    |   Milestone:  6.4.0
>  Component:  default  |     Version:  svn-develbranch6
> Resolution:           |    Keywords:
>  Platform:  All      |         Cpu:  All
> --+-
> Comment (by neteler):
>
>  Patch reduced to outstanding items (with modification for
>  raster/Makefile). Left out lib/g3d/g3dmask.c as unclear how to write it
>  correctly (see first comment here). Please test + comment.
>
>  The other issues are in 6.4.0svn and 6.5svn now.

I would really appreciate feedback:
http://trac.osgeo.org/grass/attachment/ticket/519/mingw_updated3.diff

(plus lib/g3d/g3dmask.c, see ticket)

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

[GRASS-dev] [GRASS GIS] #527: layer type is not supported yet

[GRASS GIS]

#527: layer type  is not supported yet
-+--
 Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.0
Component:  wxGUI| Version:  6.4.0 RCs
 Keywords:   |Platform:  MSWindows Vista  
  Cpu:  Unspecified  |  
-+--
 osgeo4w (2008/02/08):

 grass64rc3-2

 GDAL 1.5.4, released 2009/01/07

 data

nc_spm_08

 #landforms: entire region from 10m resolution DEM, 90m neighborhood
 (from
 
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/grasstestrast.txt)

 g.region rast=elevation
 d.erase
 r.param.scale input=elevation output=feature9c_10m size=9 param=feature
 d.rast feature9c_10m
 d.legend -c feature9c_10m at=1,30,1,3

 --

 error message pop up:

 "<1,30,1,3>:layer type  is not supported yet!

 -
 Traceback (most recent call last):
   File "C:\OSGeo4W\apps\grass\grass-6.4.0RC3\etc\wxpython\gu
 i_modules\wxgui_utils.py", line 204, in OnIdle

 self.mapdisplay.MapWindow.UpdateMap(render=True)
   File "C:\OSGeo4W\apps\grass\grass-6.4.0RC3\etc\wxpython\gu
 i_modules\mapdisp.py", line 703, in UpdateMap

 windres=windres)
   File "C:\OSGeo4W\apps\grass\grass-6.4.0RC3\etc\wxpython\gu
 i_modules\render.py", line 907, in Render

 self._renderLayers(force, mapWindow, maps, masks, opacities)
   File "C:\OSGeo4W\apps\grass\grass-6.4.0RC3\etc\wxpython\gu
 i_modules\render.py", line 852, in _renderLayers

 if not layer.Render():
   File "C:\OSGeo4W\apps\grass\grass-6.4.0RC3\etc\wxpython\gu
 i_modules\render.py", line 127, in Render

 {'type' : self.type, 'name' : self.name})
 gui_modules.gcmd
 .
 GStdError

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #527: layer type is not supported yet

[GRASS GIS]

#527: layer type  is not supported yet
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  wxGUI| Version:  6.4.0 RCs
Resolution:   |Keywords:   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by martinl):

 Replying to [ticket:527 hellik]:
 {{{
 > d.erase
 ...
 > d.legend -c feature9c_10m at=1,30,1,3
 }}}

 These commands are not supposed to work from wxGUI cmd line. Use relevant
 functions from Map Display Window.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] running v.surf.rst from GUI

[Helena Mitasova]

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


Hi,

2009/3/8 Helena Mitasova :
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  * http://gama.fsv.cvut.cz/~landa


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

Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

[Hamish]

> > Assuming that this report turns out to be not a problem, 

a segfault is not a user error, so it's pretty much guaranteed to
be a real problem and not ready to be the primary version for the
6.4.0 release without being fixed. you can't get more of a "more
testing required" red flag for a new modile than a segfault, even
if it is just for a bad-input G_fatal_error() message.

> > is there any reason not to simply replace r.mfilter with
> > r.mfilter.fp?

Glynn: 
> Only the fact that it's not 100% backwards compatible,
> although I have no idea whether anyone will actually want the
> old behaviour.

more likely if anyone will need consistency. ie they probably won't
want the old method, but they might not want to have half of their
maps one way and the other half silently different.
if it's a bug and all old maps are actually broken, I'd say fix
the bug but don't change (arguably) valid methodology.


> Apart from the use of integers, r.mfilter reads nulls as zero,

sounds like a bug- the more NULLs, the more it biases the result
towards zero. e.g. spearfish elevation is all >1000m. add a MASK
and so a bunch of zero-meter elevation into the moving window and 
you get bogus results.

or is that 0-weights not 0-value??

> while r.mfilter.fp reads nulls as null and propagates them
> (i.e. the result cell will be null if any cell in the moving
> window is null).

propagate vs not to propagate nulls is a methodology choice
(regardless of lopsided merits) and so for my 2c I'd vote to
replace it in grass7 but not devbr6 or relbr64. and of course
clearly explain the situation in the modules' help pages in the
gr6 branches.


Hamish



  

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