Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Vaclav Petras]

Hi Nikos,

I'm sorry if my comment is out of topic as I'm not following the whole
discussion, but can you just hardcode the values in the code and allow them
to be overridden by the user-specified file? That is much simpler (for both
user and GRASS) than handling paths and if the file is short, it does not
raise major code cleanness concern. If people need to edit the file, then
documentation is the appropriate place.

Vaclav

On Tue, Apr 17, 2018 at 10:32 AM, Nikos Alexandris 
wrote:

>
>
> Le Mardi 17 avril 2018, Markus Metz a écrit :
> > On Tue, Apr 17, 2018 at 4:21 PM, Nikos Alexandris <
> n...@nikosalexandris.net>
> > wrote:
> > >
> > > * Moritz Lennert  [2018-04-17 15:56:10
> > +0200]:
> > >
> > >> On 17/04/18 15:31, Nikos Alexandris wrote:
> > >>>
> > >>> Dear developers,
> > >>>
> > >>> is there a way to set a string as the content of a default "answer"
> for
> > >>> the G_OPT_F_INPUT option? I am trying to identify potential cases in
> the
> > >>> grass-addons repository, but I am not sure I have seen something
> > related.
> > >>>
> > >>> The G_OPT_F_INPUT offers a field to enter a filename. The default
> > >>> "answer", for the parser, will be the name of the file.
> > >>>
> > >>> In addition, a field to "enter values directly" is created. The
> > >>> description of this field is: "Enter file content directly instead of
> > >>> specifying a file. Temporary file will be automatically created."
> > >>>
> > >>> Can this field be filled with a pre-defined content?
> > >>> The use case is to expose, to the user, a pre-defined set of
> > >>> reclassification rules. These will help a beginner to get started,
> > >>> understand easier and modify rules as he sees fit.
> > >>
> > >>
> > >> Use the 'answer' parameter:
> > >>
> > >> #% answer : myfilename
> > >>
> > >> Moritz
> > >
> > >
> > > It works: it loads the content of an external file. Are we forced to
> use
> > > external files in such a case? Which means an extra file has to be
> > > shipped with the source code.
> > > Can we not use an in-script hardcoded string for example?
> >
> > Be aware that you can't use a hardcoded full path, because depending on
> the
> > installation/user/os, that path may or may not exist. If you use a
> relative
> > path, that path is relative to the current working directory which is of
> > course not constant between sessions/installation/user/os. I'm afraid a
> > default answer to G_OPT_F_INPUT will cause a lot of trouble.
> >
> > my2c
> >
> > Markus M
>
> Ciao Markus.
>
> Yet my intention was/is to use a hardcoded string of rules. Not a path to
> a file.
>
> It appears the only option is to document, the rules, and suggest a copy
> and paste in to the corresponding field.
>
> Can the parser be extended in this regard with yet another option? Perhaps
> I missed some existing option (?).
>
> Thank you Markus, Nikos
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Helmut Kudrnovsky]

NikosAlexandris wrote
> Yet my intention was/is to use a hardcoded string of rules. Not a path to
> a file.
> 
> It appears the only option is to document, the rules, and suggest a copy
> and paste in to the corresponding field.
> 
> Can the parser be extended in this regard with yet another option? Perhaps
> I missed some existing option (?).

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.habitat.dem/v.habitat.dem.py#L568

in this script I write out a text file for a predefined color rule and later
on

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.habitat.dem/v.habitat.dem.py#L579

I use it. it's an ugly hack, maybe you can use it without writing a text
file.





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Moritz Lennert]

On 17/04/18 16:21, Nikos Alexandris wrote:

* Moritz Lennert  [2018-04-17 15:56:10 +0200]:


On 17/04/18 15:31, Nikos Alexandris wrote:

Dear developers,

is there a way to set a string as the content of a default "answer" for
the G_OPT_F_INPUT option? I am trying to identify potential cases in the
grass-addons repository, but I am not sure I have seen something related.

The G_OPT_F_INPUT offers a field to enter a filename. The default
"answer", for the parser, will be the name of the file.

In addition, a field to "enter values directly" is created. The
description of this field is: "Enter file content directly instead of
specifying a file. Temporary file will be automatically created."

Can this field be filled with a pre-defined content?
The use case is to expose, to the user, a pre-defined set of
reclassification rules. These will help a beginner to get started,
understand easier and modify rules as he sees fit.


Use the 'answer' parameter:

#% answer : myfilename

Moritz


It works: it loads the content of an external file. Are we forced to use
external files in such a case? Which means an extra file has to be
shipped with the source code.

Can we not use an in-script hardcoded string for example?


Sure you can.

Use write_command() with stdin=text that you wish to feed into 
r.reclass. You can find several examples of its usage in existing scripts.


Moritz

P.S. Thanks to MarkusM for raising the point about file path difficulties...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Nikos Alexandris]

Le Mardi 17 avril 2018, Markus Metz a écrit :
> On Tue, Apr 17, 2018 at 4:21 PM, Nikos Alexandris 
> wrote:
> >
> > * Moritz Lennert  [2018-04-17 15:56:10
> +0200]:
> >
> >> On 17/04/18 15:31, Nikos Alexandris wrote:
> >>>
> >>> Dear developers,
> >>>
> >>> is there a way to set a string as the content of a default "answer" for
> >>> the G_OPT_F_INPUT option? I am trying to identify potential cases in the
> >>> grass-addons repository, but I am not sure I have seen something
> related.
> >>>
> >>> The G_OPT_F_INPUT offers a field to enter a filename. The default
> >>> "answer", for the parser, will be the name of the file.
> >>>
> >>> In addition, a field to "enter values directly" is created. The
> >>> description of this field is: "Enter file content directly instead of
> >>> specifying a file. Temporary file will be automatically created."
> >>>
> >>> Can this field be filled with a pre-defined content?
> >>> The use case is to expose, to the user, a pre-defined set of
> >>> reclassification rules. These will help a beginner to get started,
> >>> understand easier and modify rules as he sees fit.
> >>
> >>
> >> Use the 'answer' parameter:
> >>
> >> #% answer : myfilename
> >>
> >> Moritz
> >
> >
> > It works: it loads the content of an external file. Are we forced to use
> > external files in such a case? Which means an extra file has to be
> > shipped with the source code.
> > Can we not use an in-script hardcoded string for example?
> 
> Be aware that you can't use a hardcoded full path, because depending on the
> installation/user/os, that path may or may not exist. If you use a relative
> path, that path is relative to the current working directory which is of
> course not constant between sessions/installation/user/os. I'm afraid a
> default answer to G_OPT_F_INPUT will cause a lot of trouble.
> 
> my2c
> 
> Markus M

Ciao Markus.

Yet my intention was/is to use a hardcoded string of rules. Not a path to a 
file.

It appears the only option is to document, the rules, and suggest a copy and 
paste in to the corresponding field.

Can the parser be extended in this regard with yet another option? Perhaps I 
missed some existing option (?).

Thank you Markus, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3510: wxpython 4: fix warnings for Attribute Table Manager

[GRASS GIS]

#3510: wxpython 4: fix warnings for Attribute Table Manager
--+-
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  minor|  Milestone:  7.6.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:  fixed|   Keywords:  wxpython 4, attribute table
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by annakrat):

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


Comment:

 Backported in r72625.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3505: Opening a workspace file

[GRASS GIS]

#3505: Opening a workspace file
--+-
  Reporter:  clerici  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.4.1
 Component:  wxGUI|Version:  7.4.0
Resolution:  fixed|   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-
Changes (by annakrat):

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


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3505: Opening a workspace file

[GRASS GIS]

#3505: Opening a workspace file
--+-
  Reporter:  clerici  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.4.1
 Component:  wxGUI|Version:  7.4.0
Resolution:   |   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by annakrat):

 In [changeset:"72624" 72624]:
 {{{
 #!CommitTicketReference repository="" revision="72624"
 wxGUI: correctly delete layertree, see #3505 (merge from trunk, r72455)
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Markus Metz]

On Tue, Apr 17, 2018 at 4:21 PM, Nikos Alexandris 
wrote:
>
> * Moritz Lennert  [2018-04-17 15:56:10
+0200]:
>
>> On 17/04/18 15:31, Nikos Alexandris wrote:
>>>
>>> Dear developers,
>>>
>>> is there a way to set a string as the content of a default "answer" for
>>> the G_OPT_F_INPUT option? I am trying to identify potential cases in the
>>> grass-addons repository, but I am not sure I have seen something
related.
>>>
>>> The G_OPT_F_INPUT offers a field to enter a filename. The default
>>> "answer", for the parser, will be the name of the file.
>>>
>>> In addition, a field to "enter values directly" is created. The
>>> description of this field is: "Enter file content directly instead of
>>> specifying a file. Temporary file will be automatically created."
>>>
>>> Can this field be filled with a pre-defined content?
>>> The use case is to expose, to the user, a pre-defined set of
>>> reclassification rules. These will help a beginner to get started,
>>> understand easier and modify rules as he sees fit.
>>
>>
>> Use the 'answer' parameter:
>>
>> #% answer : myfilename
>>
>> Moritz
>
>
> It works: it loads the content of an external file. Are we forced to use
> external files in such a case? Which means an extra file has to be
> shipped with the source code.
> Can we not use an in-script hardcoded string for example?

Be aware that you can't use a hardcoded full path, because depending on the
installation/user/os, that path may or may not exist. If you use a relative
path, that path is relative to the current working directory which is of
course not constant between sessions/installation/user/os. I'm afraid a
default answer to G_OPT_F_INPUT will cause a lot of trouble.

my2c

Markus M
>
> Thank you Moritz, Nikos
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Nikos Alexandris]

* Moritz Lennert  [2018-04-17 15:56:10 +0200]:


On 17/04/18 15:31, Nikos Alexandris wrote:

Dear developers,

is there a way to set a string as the content of a default "answer" for
the G_OPT_F_INPUT option? I am trying to identify potential cases in the
grass-addons repository, but I am not sure I have seen something related.

The G_OPT_F_INPUT offers a field to enter a filename. The default
"answer", for the parser, will be the name of the file.

In addition, a field to "enter values directly" is created. The
description of this field is: "Enter file content directly instead of
specifying a file. Temporary file will be automatically created."

Can this field be filled with a pre-defined content?
The use case is to expose, to the user, a pre-defined set of
reclassification rules. These will help a beginner to get started,
understand easier and modify rules as he sees fit.


Use the 'answer' parameter:

#% answer : myfilename

Moritz


It works: it loads the content of an external file. Are we forced to use
external files in such a case? Which means an extra file has to be
shipped with the source code. 


Can we not use an in-script hardcoded string for example?

Thank you Moritz, Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Moritz Lennert]

On 17/04/18 15:31, Nikos Alexandris wrote:

Dear developers,

is there a way to set a string as the content of a default "answer" for
the G_OPT_F_INPUT option? I am trying to identify potential cases in the
grass-addons repository, but I am not sure I have seen something related.

The G_OPT_F_INPUT offers a field to enter a filename. The default
"answer", for the parser, will be the name of the file.

In addition, a field to "enter values directly" is created. The
description of this field is: "Enter file content directly instead of
specifying a file. Temporary file will be automatically created."

Can this field be filled with a pre-defined content?
The use case is to expose, to the user, a pre-defined set of
reclassification rules. These will help a beginner to get started,
understand easier and modify rules as he sees fit.


Use the 'answer' parameter:

#% answer : myfilename

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

[GRASS-dev] Default content for the "answer" to G_OPT_F_INPUT

[Nikos Alexandris]

Dear developers,

is there a way to set a string as the content of a default "answer" for
the G_OPT_F_INPUT option? I am trying to identify potential cases in the
grass-addons repository, but I am not sure I have seen something related.

The G_OPT_F_INPUT offers a field to enter a filename. The default
"answer", for the parser, will be the name of the file.

In addition, a field to "enter values directly" is created. The
description of this field is: "Enter file content directly instead of
specifying a file. Temporary file will be automatically created."

Can this field be filled with a pre-defined content?
The use case is to expose, to the user, a pre-defined set of
reclassification rules. These will help a beginner to get started,
understand easier and modify rules as he sees fit.

Thank you, Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Impossible to kill r.in.gdal

[Markus Neteler]

On Mon, Apr 16, 2018 at 4:30 PM, Luca Delucchi  wrote:
> Hi devs,
>
> I'm importing raster dataset with r.in.gdal but I have a problem
> because the processes seems to died but they didn't stop and I'm not
> neither able to kill them, any idea?
>
>  r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
> output=T_2M_1997_05 memory=4048 -o
> No projection information available
> Over-riding projection check
> Importing 744 raster bands...
> Importing raster map ...
>  100%
> ^C^C^C^C^C^C^C^C^C^C^C^C^Z
> ^C
> ^C^C^C^C^Z^C
> ^Z^Z

It looks like that the sas1/ device is hanging.

> ps aux | grep r.in.gdal
> lucadelu  9486  0.0  0.1 415908 37880 ?DApr12   0:00
> r.in.gdal 
> input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199901.nc
> memory=6072 title=COSMO REA6 offset=0 num_digits=0
> output=RELHUM_2M_1999_01 -o --q

--> D state
https://stackoverflow.com/questions/20423521/process-permanently-stuck-on-d-state


...
> killall -9 r.in.gdal

vs
...
> kill -9 9486 9493 16182 16185 43603 47014 47540

killall does not offer -9 but with D state the zombie process cannot
be killed anyway.

So: reboot is the only way (and fix the mounting of the device).

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

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Veronica Andreo]

Dear Markus,

Thanks much for such a quick fix!!! Awesome! :)

Cheers,
Vero

2018-04-16 11:32 GMT+02:00 Markus Metz :

>
>
> On Sun, Apr 15, 2018 at 10:49 PM, Markus Neteler 
> wrote:
> >
> > On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler 
> wrote:
> > > On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo 
> wrote:
> > >> Hi devs,
> > >>
> > >> I just found something odd. I have a CHIRPS tif for Africa [0], but I
> would
> > >> only need to import Ghana, so I used r.in.gdal -r. However when I
> visualize
> > >> the data, most of it is nodata, while the full map of Africa has data
> all
> > >> over the continent. Then, I tried also with r.import extent=region.
> Same
> > >> result. The only thing providing what I expected to be the right
> result (a
> > >> subset from the full map) is importing the whole map and then using
> > >> r.mapcalc to clip (i need the space in my hard disk)
> >
> > trying harder I can reproduce the issue (of course not NULL related).
> >
> > So, I have no clue right now why it behaves differently.
>
> fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug in
> r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.
>
> Markus M
>
> >
> > markusN
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev