Re: [GRASS-dev] r.distance: 'maps=map1, map2' vs 'maps=map1 maps=map2'

[Glynn Clements]

Maciej Sieczka wrote:

> I have discovered an undocumented feature (?) in r.distance.
> 
> The manual reads:
> 
> r.distance maps=map1,map2
> 
> When I specify it as:
> 
> r.distance maps=map1 maps=map2
> 
> it works as well.

This is a feature of the parser, and works for all modules.

> The order can also be controlled this way. I.e.:
> 
> r.distance maps=map1,map2 is equivalent to r.distance maps=map1 maps=map2
> 
> and:
> 
> r.distance maps=map2,map1 is equivalent to r.distance maps=map2 maps=map1
> 
> Can I rely on this behavior or may it change in future? Currently it 
> works for 6.4 svn and 7 svn.

It isn't expected to change. It's useful for constructing argument
lists using xargs, e.g.:

... | sed 's/^/map=/' | xargs g.something ...

This is much harder to achieve using the opt=val,val,val,... syntax.

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

Re: [GRASS-dev] current state of r.li

[Hamish]

Paolo wrote:
> As some of you know, the r.li suite of GRASS
> commands allows landscape analyses[0]. Its
> interface is rather complex, and is still in
> TclTk, not ported to either wxpython or qgis. As
> such, it is now more difficult to use than it
> should be, and it will become unusable when TclTk
> support will be dropped.
> The possible solution (thanks Radim) is to rewrite
> the interface as a qgis python plugin. It should
> not be a huge work

Hi,

I just looked at r.li.setup's .tcl files. it is some
work but as you say not a huge amount to port it to
another GUI frontend. (circa one dozen functions,
~1000 lines of code)

there is no reason to only do qgis or wxPython, we
should do both!

http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.li/r.li.setup


the bigger issue for r.li was r.li.daemon et al
using UNIXisms which didn't work on MS Windows..
but IIRC Glynn already fixed that in grass7?


Hamish



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

[GRASS-dev] Re: [GRASS GIS] #596: provide a grass-config script

[GRASS GIS]

#596: provide a grass-config script
--+-
 Reporter:  hamish|   Owner:  grass-...@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Installation  | Version:  svn-trunk
 Keywords:  gdal-plugin   |Platform:  All  
  Cpu:  All   |  
--+-
Changes (by wolf):

 * cc: wolf (added)


Comment:

 The file grass-config.patch adds a basic version of what grass-config
 could be. Note that it uses the configured values of /prefix and so on to
 figure out where GRASS has been installed. Applies to trunk. This can be
 expanded to have more options or more varied options...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.distance: 'maps=map1, map2' vs 'maps=map1 maps=map2'

[Maciej Sieczka]

W dniu 11.11.2010 18:22, Maciej Sieczka pisze:

Hi,

I have discovered an undocumented feature (?) in r.distance.

The manual reads:

r.distance maps=map1,map2

When I specify it as:

r.distance maps=map1 maps=map2

it works as well.

The order can also be controlled this way. I.e.:

r.distance maps=map1,map2 is equivalent to r.distance maps=map1 maps=map2

and:

r.distance maps=map2,map1 is equivalent to r.distance maps=map2 maps=map1

Can I rely on this behavior or may it change in future? Currently it
works for 6.4 svn and 7 svn.


I'm asking this because the 'maps=map1 maps=map2' syntax would let me 
add the command to QGIS GRASS toolbox - now. Otherwise, it would require 
adding support for 'maps=map1,map2' syntax - unknown if/when would be 
implemented.


Maciek

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

[GRASS-dev] current state of r.li

[Paolo Cavallini]

Hi all.
Sorry for crossposting. As some of you know, the r.li suite of GRASS 
commands allows landscape analyses[0]. Its interface is rather complex, 
and is still in TclTk, not ported to either wxpython or qgis. As such, 
it is now more difficult to use than it should be, and it will become 
unusable when TclTk support will be dropped.
The possible solution (thanks Radim) is to rewrite the interface as a 
qgis python plugin. It should not be a huge work (we provisionally 
estimate 2-3 weeks).
The question is: is there anybody willing to invest either his/her time, 
or some money, to write such a plugin?

We (Faunalia) would be happy to help if necessary.
All the best.
--
http://www.faunalia.it/pc

[0]http://grass.fbk.eu/gdp/html_grass64/r.li.setup.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev