Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules

[GRASS GIS]

#2008: grass.script's find_program() can't find modules
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  critical  |   Milestone:  6.4.4
 Component:  Python| Version:  svn-releasebranch64  
Resolution:|Keywords:  find_program()   
  Platform:  All   | Cpu:  x86-64   
---+

Comment(by wenzeslaus):

 == find_program ==

 Replying to [comment:31 hamish]:
 > Replying to [comment:29 wenzeslaus]:
 > > It could be convenient (for both the interface and implementation) to
 > > have special function to test presents of GRASS modules.
 >
 > just to note that the last version of that I saw failed to pick up Addon
 modules.
 > (installed in either the GRASS_ADDON_PATH(s) &/or ~/bin/)
 >
 Did you test r56869? To be honest, I never remember if `GRASS_ADDON_PATH`
 is in `PATH`. If it is not in `PATH`, `find_program` (`test/run_program`)
 probably not work for addons. Maybe another reason for creating new
 function for modules. We can even call it `is_module_present/here` to
 create nicely readable code. You can provide your suggestions, especially
 those English-correct. The implementation is clear: same as current
 (glynn's) `find_program` (run the module), `help` parameter added and all
 GRASS acceptable paths used.

 == test in g.manual ==

 Replying to [comment:30 hamish]:
 > Replying to [comment:29 wenzeslaus]:
 > > Anyway, in r56880 I have deleted the test in g.manual since I
 > > don't see any reason for it.
 >
 > In r56882 I have put it back. It is nice to have the clearer error
 message on Linux (where the error could come up a lot), and in cases where
 GRASS_HTML_BROWSER is either unset of malformed. It may need to be
 improved or fixed, but it should be there.
 >

 Tell me examples, please. I don't see much difference between "''Browser
 '%s' not found''" and "''Error starting browser '%(browser)s' for HTML
 file '%(path)s'''".

 Since the test (`find_program`) does not work for clear examples such as
 `firefox`, I don't see the reason to keep the test there to produce just
 slightly better error message in other cases (moreover, the meaning of the
 message is absolutely clear only if you know, which function/test caused
 this message, IMHO).

 Anyway, if you think that the test is necessary, we can use the
 `shutil.which` function to do the test. Thus, we will have two functions,
 as already proposed by annakrat in comment:25.

 == opening HTML page ==

 Replying to [comment:32 glynn]:
 > Replying to [comment:29 wenzeslaus]:
 >
 > > > More generally, there should probably be separate functions for
 "opening" a file or URL in the user's desktop environment.
 > >
 > > Sorry, I don't get your last point. Would you like to have
 `open_something` function in GRASS or do you expect this function to be
 available from system or something else?
 >
 > I think that GRASS should have something. On Windows, this doesn't
 require testing for specific programs; subprocess.call(file, shell=True)
 should suffice.
 >
 > > Diverging from the original ticked topic, the
 `GRASS_HTML_BROWSER=firefox` blocks the command line even after r56880
 when no firefox session is running. However, this is expected and I think
 there is no way how to avoid this when we want (probably because of cmd
 line web browsers) to use `execlp`.
 >
 > GRASS_HTML_BROWSER is probably too simplistic. E.g. a GUI browser should
 be executed in the background, whereas e.g. lynx shouldn't. But something
 like xdg-open should probably be preferred.


 As for the ''opening file topic'', we shall create new ticked. However,
 for now, I have to say that I don't like the idea of re-implementation of
 the `xdg-open`-like functionality in GRASS, especially when primary
 backend will be something like `xdg-open` or standard windows
 functionality. Although I agree that the current state is insufficient.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] pyGRASS problem with r.sun

[Pietro Zambelli]

Hi Yann,

On Sunday 23 Jun 2013 11:15:46 Yann Chemin wrote:
> Hi,
> 
> (svn trunk)
> 
> r.sun in pyGRASS is somehow confused with data type for time option.
> 
> Time option does work well as a float input directly in the shell.
> from pyGRASS it expects an integer.
> 
> time=10.3321830777
> Traceback (most recent call last):
>   File "./python-pygrass.py", line 293, in 
>
> r.sun(elevin="dem",albedo=b_albedo,glob_rad=b_rnet,lin=3.0,day=b_doy,time=f
> loat(local_time),quiet=QIET,overwrite=OVR) File
> "/usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/module
> .py", line 183, in __call__
> self.inputs[key].value = val
>   File
> "/usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/parame
> ter.py", line 98, in _set_value
> (self.name, self.values))
> ValueError: The Parameter , must be one of: [0, 1, 2, 3, 4, 5,
> 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
> 24]

Good point! :-)

should be fixed in r56885

{{{
>>> from pygrass.modules.shortcuts import raster as r
>>> sun = r.sun
>>> sun.inputs.time = 10.5   # it's fine
>>> sun.inputs.time = 110.5  # raise an exception
Traceback (most recent call last):
  File "", line 1, in 
sun.inputs.time = 110.5
  File "pygrass/modules/interface/typedict.py", line 25, in __setattr__
self[key].value = value
  File "pygrass/modules/interface/parameter.py", line 99, in _set_value
self.values[-1]))
ValueError: The Parameter , must be: 0<=value<=24

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

Re: [GRASS-dev] GSOC wk1 checkin

[Pierre Roudier]

Hi Tim, Hamish et al.,

Just jumping in the discussion, FYI: I am following the project with
much attention, in particular because I am working with soil data,
both at the national scale in NZ, but also on international project
that aim at storing important amounts of data [www.globalsoilmap.net].

The soil science community has recognised the difficulty to deal with
the storage of soil horizon data, and a specific working group has
been formed under the auspices of the International Union of Soil
Sciences [www.soilinformationstandards.org/content/about].

We've already been developing data models for storing soil data, I'd
be happy to point you towards these if that is of interest for your
project.

Tim, all the best for your summer project,
Hamish, hang on tight for this cold winter blast!

Talk soon,

Pierre


2013/6/23 Hamish :
> Hi Tim, glad to see you're underway.
>
> is it possible to post some data samples on your project's blog? (a 
> description + figure would be great) It would help to get a better idea of 
> what the import options would be for those three datasets. What form is the 
> Natural Resources Conservation Service survey data in?
> If you like/need I can poke around here for some more datasets.
>
>> My work product next week is going to focus on the interpolation
>> module. The abstract workflow for the module as whole is as follows
>>
>> Process for generation of r3 voxel grid from a population of xy
>> located 1 dimensional horizon descriptions
>>  1. Import of database horizon descriptions
>>  2. Generation of line vector representing the path of the horizon
>>  description in xyz
>
> note that GRASS vector lines can not store per-vertex attribute data,
> only per-line attribute data. Anything else must be stored as points;
> see the v.in.gps module. one idea is to trick the vector engine into storing 
> depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the 
> results at the last step when you need real earth-coord x,y,z.
> ?
>
>>  3. Segmentation of the line vector into n number xyz points
>
> so binning by depth segment?
>
>>  4. query of attribute values to points from attribute database
>>  5. Generation of r3 region
>>  6. Interpolation of point attribute values through geostatistical
>>   and/or logical operators onto voxel grid locations
>
> wrt to single x,y location well log, it seems to me like the r3.in.xyz
> module already gives you most of that, bypassing the vector line stage
> completely. binning 3D data into voxels using univariate statistics is 
> precisely what it does.
>
> are you looking to interpolate/aggregate vertically first, then
> horizontally? would you interpolate at each depth band separately
> then combine those together?
>
> how well does that work with dipping angles? perhaps v.vol.rst could help 
> too, to interpolate everything at once in a more 3D-influenced model?
>
>> One point that Ben articulated was that the interpolation assignment
>> needs to be capable of operating on integer data so that it can work
>> on
>
> that got cut off, but I guess you mean categorical value, so nearest
> neighbour is needed, and not linear, cubic, or spline.
>
>> Best wishes on this first day of summer.
>
> Up to my knees in snow yesterday, but good mountain boots and funner than the 
> rain and sleet that was falling down in the valley. :)
>
>
> regards,
> Hamish
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC wk1 checkin

[Hamish]

Hi Tim, glad to see you're underway.

is it possible to post some data samples on your project's blog? (a description 
+ figure would be great) It would help to get a better idea of what the import 
options would be for those three datasets. What form is the Natural Resources 
Conservation Service survey data in?
If you like/need I can poke around here for some more datasets.

> My work product next week is going to focus on the interpolation
> module. The abstract workflow for the module as whole is as follows
>
> Process for generation of r3 voxel grid from a population of xy
> located 1 dimensional horizon descriptions
>  1. Import of database horizon descriptions
>  2. Generation of line vector representing the path of the horizon
>  description in xyz

note that GRASS vector lines can not store per-vertex attribute data,
only per-line attribute data. Anything else must be stored as points;
see the v.in.gps module. one idea is to trick the vector engine into storing 
depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the 
results at the last step when you need real earth-coord x,y,z.
?

>  3. Segmentation of the line vector into n number xyz points

so binning by depth segment?

>  4. query of attribute values to points from attribute database
>  5. Generation of r3 region
>  6. Interpolation of point attribute values through geostatistical
>   and/or logical operators onto voxel grid locations

wrt to single x,y location well log, it seems to me like the r3.in.xyz
module already gives you most of that, bypassing the vector line stage
completely. binning 3D data into voxels using univariate statistics is 
precisely what it does.

are you looking to interpolate/aggregate vertically first, then
horizontally? would you interpolate at each depth band separately
then combine those together?

how well does that work with dipping angles? perhaps v.vol.rst could help too, 
to interpolate everything at once in a more 3D-influenced model?

> One point that Ben articulated was that the interpolation assignment
> needs to be capable of operating on integer data so that it can work
> on

that got cut off, but I guess you mean categorical value, so nearest
neighbour is needed, and not linear, cubic, or spline.

> Best wishes on this first day of summer. 

Up to my knees in snow yesterday, but good mountain boots and funner than the 
rain and sleet that was falling down in the valley. :)


regards,
Hamish

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