Re: [GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 The VAR file in the mapset contains this:


 {{{
 DB_DRIVER: pg
 DB_DATABASE: testgrass
 }}}

 i.e. no info about the host. Is this normal ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:12 annakrat]:
 > OK, try r69580. First remove the snapping record in your settings file.
 Save it in trunk, and now open the dialog in older GRASS. Save it and open
 it again in trunk. If there are no problems, I will backport it.

 This seems to work, except: when I chose map units in trunk, I get the
 following in the settings file:


 {{{
 vdigit;snapping;units;screen pixels;value;25;unit;1
 }}}

 which looks a bit contradictory ('unit: 1' should be 'units: map units',
 or ?).

 When I open this in grass70, I get values corresponding to 25 pixels,
 although the drop-down list status does not show any choice. When I then
 choose pixels, I first get 25 pixels = 25 meters, but when I change the
 number of pixels, the meter info is correct again.

 Trying to save from grass70, nothing is saved to the settings file if I
 choose map units. Choosing screen pixels, I only get:

 {{{
 vdigit;snapping;
 }}}

 in the settings file.

 When I then open trunk, it gives me the default settings of 10 screen
 pixels.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Moritz Lennert]

On 26/09/16 23:50, Vaclav Petras wrote:


On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo > wrote:

I'm with MaDi in that if I see a very long list of flags and
parameters in the terminal when using --h, i just go to the
manual... I just use --h in CLI for a quick recalling of
flags/options... A reduced list of most commonly used flags would be
nice, but still keep the possibility to get the advanced
flags/parameters as well, if the user needs more info...


If the --help is just for scanning and the issue is that it simply too
long, hiding some parameters is not the only option we have. For many
(and more in the future hopefully) parameters we have (short) label and
(longer) description. --help prints both (if both are present, that's at
least 2 lines per parameter). Additionally, if the option has predefined
values which have descriptions, there is one line for each of those. So,
the question is would it be helpful (at least as a first step) if --help
would print less information for each parameter but still provided all
parameters?


In line with your other mail where you caution about "hiding" useful 
information, how about not changing the --help output, but rather adding 
a "--simple-help" or somthing like this which would output a simplified 
help. Although:



and manual pages then (a tab or section for advanced
flags/parameters)...


Considering that we have currently as system of (gui) sections which
place the options to individual tabs in GUI, isn't showing the different
sections in the manual the right thing to do?


I would prefer this: show everything, but structure it differently, i.e. 
possibly introduce a new parser keyword (advanced: yes) which would put 
the option into a specific section of the manual. IMHO, this should be 
independent of the GUI sections logic as one might to group less 
advanced and advanced options in the same thematic tab...



IMHO, a major issue however is the lack of examples for the usage of
more advanced flags or options (or even the required and more common
ones). Take the case of several i.* modules, for example... but maybe
this should go in a separate thread :-)

>
>
> Good point. If you have an explanation and example for a flag, perhaps
> you can understand it and it is not so advanced at the end.

I think this is actually a major issue: man pages without description, 
notes and example sections are almost useless IMHO. At the foss4g.be 
last week someone presented a simple use of GRASS GIS (to create this 
map [1] for television) and explained how he actually found the GRASS 
GIS manual system extremely well done and useful, because of the 
explanations and examples...


Moritz

[1] http://www.rtbf.be/services/meteo/apere

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Vaclav Petras]

On Fri, Sep 23, 2016 at 5:22 PM, Markus Neteler  wrote:

> * various commands: "Use the low-memory version" - also more advanced


I guess this is a typical example where we need to be careful. I can
imagine a situation when a beginner has a lot of data and low-end hardware.
By hiding an parameter like this, we would make it even more advanced. Now
you not only need to understand that your hardware is not enough and that
the algorithm should somehow account for that. You also need to know that
there might be a hidden option for that and you need to know how to find
it. Having this in the manual or even a Memory or Speed tab in the GUI,
gives some hope that even a beginner will be able to use it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Adding an expert mode to the parser

[Vaclav Petras]

On Fri, Sep 23, 2016 at 5:22 PM, Markus Neteler  wrote:

> Maybe not hide then but at least group the parameters and flags rather
> than alpha-order or random mix.
>

This is something which can be done right now. The options and flags are
presented in the order as they are defined in the source code. These
additional rules currently apply in general: (one letter) flags are listed
before (key-value) options. Long (multi-letter standard) flags are listed
in between them. Additionally in GUI, before this sorting, the options and
flags are always sorted to the tabs according to the specified (or
automatically generated) (gui) sections. Typically options and flags
(separately or combined) with (gui) section are specified together in the
source code, consequently they are grouped in --help and manual (but
without visible borders or any other indication).

Of course, this doesn't mean that the (gui) section cannot be contain, for
example 'basic', 'common' and 'advanced' subsections.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Adding an expert mode to the parser

[Vaclav Petras]

On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo 
wrote:

> I'm with MaDi in that if I see a very long list of flags and parameters in
> the terminal when using --h, i just go to the manual... I just use --h in
> CLI for a quick recalling of flags/options... A reduced list of most
> commonly used flags would be nice, but still keep the possibility to get
> the advanced flags/parameters as well, if the user needs more info...
>

If the --help is just for scanning and the issue is that it simply too
long, hiding some parameters is not the only option we have. For many (and
more in the future hopefully) parameters we have (short) label and (longer)
description. --help prints both (if both are present, that's at least 2
lines per parameter). Additionally, if the option has predefined values
which have descriptions, there is one line for each of those. So, the
question is would it be helpful (at least as a first step) if --help would
print less information for each parameter but still provided all parameters?


> and the same in the GUI
>

In the case of GUI, we should first answer the question why are the
sections/tabs not enough? Because they already should separate basic and
advanced while providing actually much finer and partially self-documenting
way (for example, you fill in Required tab, go also to Selection, but leave
aside Transformation and Advanced tabs).


> and manual pages then (a tab or section for advanced flags/parameters)...
>
>
Considering that we have currently as system of (gui) sections which place
the options to individual tabs in GUI, isn't showing the different sections
in the manual the right thing to do? This would not only make the manual
more organized, but it would also link the manual more to the GUI.
Depending how good and smart are we with the styling and JavaScript we can
even hide some by default. But perhaps there is a reason why this is not
enough.


> IMHO, a major issue however is the lack of examples for the usage of more
> advanced flags or options (or even the required and more common ones). Take
> the case of several i.* modules, for example... but maybe this should go in
> a separate thread :-)
>

Good point. If you have an explanation and example for a flag, perhaps you
can understand it and it is not so advanced at the end.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Adding an expert mode to the parser

[Veronica Andreo]

Hello

I'm with MaDi in that if I see a very long list of flags and parameters in
the terminal when using --h, i just go to the manual... I just use --h in
CLI for a quick recalling of flags/options... A reduced list of most
commonly used flags would be nice, but still keep the possibility to get
the advanced flags/parameters as well, if the user needs more info... and
the same in the GUI and manual pages then (a tab or section for advanced
flags/parameters)...

IMHO, a major issue however is the lack of examples for the usage of more
advanced flags or options (or even the required and more common ones). Take
the case of several i.* modules, for example... but maybe this should go in
a separate thread :-)

Cheers,
Vero

2016-09-26 6:01 GMT-03:00 Margherita Di Leo :

> Hi,
>
> On Fri, Sep 23, 2016 at 12:00 AM, Markus Neteler 
> wrote:
>
>> Hi,
>>
>> in order to not hinder the addition of important new flags/parameters
>> to modules while keeping things optionally easy it would be good to
>> implement some expert mode to the parser.
>>
>> The flags and parameters for advanced users should be hidden by
>> default (maybe by using an extra definition in order to "tag" them in
>> the source code). Then e.g. by setting a variable they would become
>> visible in the help text and GUI.
>> Probably they should be always accepted when being invoked.
>>
>
>  This makes sense to me. If I type name.module --help and the command line
> yield too long a list of parameters, I normally prefer reading it on the
> manual page, where it is more clear, and I find extremely useful the usage
> examples of the flags. I don't find it very informative to list all the
> flags in command line, even the less used. There could be for example a
> --ext-help for extended help display. So for example, typing only --help
> would list only most used options and would end with "type --ext-help for
> extended help" or something like that.
>
> My 2 c
>
> --
> Margherita Di Leo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3153: g.gui.animation freezes when trying to add decorations

[GRASS GIS]

#3153: g.gui.animation freezes when trying to add decorations
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.animation
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by veroandreo):

 Sorry for the delay...

 I just select a raster or vector time series to display, then go to
 "export animation" and before actually exporting, I add some decoration,
 i.e.: timestamp, image or text, and when I click over export, rather
 nothing happens or "Preparing export, please wait..." sign freezes in the
 screen forever, while in the output window, I get the same error as
 reported before...

 System info:

 {{{
 GRASS version: 7.3.svn
 GRASS SVN revision: r69574M
 Build date: 2016-09-26
 Build platform: x86_64-pc-linux-gnu
 GDAL: 2.0.2
 PROJ.4: 4.9.2
 GEOS: 3.5.0
 SQLite: 3.13.0
 Python: 2.7.12
 wxPython: 3.0.2.0
 Platform: Linux-4.7.4-200.fc24.x86_64-x86_64-with-fedora-24-Twenty_Four
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3166: Parallelization with tiling for grass.script

[GRASS GIS]

#3166: Parallelization with tiling for grass.script
--+--
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  script, parallel
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by huhabla):

 IMHO, the for-loop to setup the processing commands for the TiledWorkflow
 can be avoided when using the PyGRASS Module and MultiModule approach. The
 PyGRASS Module objects allows to alter the input and output settings
 before running, so that the TiledWorkflow class could take care of the
 tile names, altering the user pre-configured Module objects. The user
 simply initiates the Modules that should be used with the original raster
 names. The PyGRASS Module allows deep copy operation to clone the existing
 Module objects, hence the TiledWorkflow can create any number of copies
 and replacing the raster names with tile names.

 Please have a look at the PyGRASS Module initialization in
 t.rast.neighbors:
 
https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.neighbors/t.rast.neighbors.py#L135

 Cloning and adding to the parallel queue:
 
https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.neighbors/t.rast.neighbors.py#L168

 Cite:
 >
 > The implementation is now 300 lines. MultiModule alone has 200
 >

 Well it is not much "Code". The doctests and the description of
 MultiModule are more than 100 lines. ;)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 OK, try r69580. First remove the snapping record in your settings file.
 Save it in trunk, and now open the dialog in older GRASS. Save it and open
 it again in trunk. If there are no problems, I will backport it.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3166: Parallelization with tiling for grass.script

[GRASS GIS]

#3166: Parallelization with tiling for grass.script
--+--
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  script, parallel
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by wenzeslaus):

 Replying to [comment:1 mlennert]:
 > Wow, this looks great !

 Note also what is in PyGRASS. Especially after r69507.

 > Could you just explain the relation

 Partial duplication. As in the case of `grass.script` and
 `grass.pygrass.modules`.

 > difference between this and the GridModule in pygrass ?

 * This supports list of modules (workflow) which are executed subsequently
 on the given tile.
 * User needs to prepare the list in a for loop (as opposed to not using
 any for loop). This is because it is in fact derived from the non-tiled
 parallelization API which is more general, so the user in fact loops over
 what needs to be done (with or without parallelization).
 * Related to that, the API for simple parallel processing, parallel
 processing of series of maps, and tiled parallel processing of series of
 maps is the same.
 * User needs to "help" the functions and objects by providing the with
 some metadata, i.e. types and names of the maps to patch (for patching),
 because no module run metadata are available in `grass.script`.
 * Some of the execution details are lost, e.g. only last command's textual
 output is preserved.
 * `GridModule` uses separate mapsets for individual tiles, this uses
 `WIND_OVERRIDE`.
 * `GridModule` uses PyGRASS ctypes wrappers for patching, this
 (potentially huge) expression `r.mapcalc` and `r3.mapcalc`.
 * The interface is like `grass.script`, not like `grass.pygrass.modules`.
 * It is not complete.
 * The implementation is now 300 lines. `MultiModule` alone has 200.
 * It uses from multiprocessing `Pool.map_async` function (which may be the
 cause of problem with interrupting).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:10 annakrat]:
 > Replying to [comment:9 mlennert]:
 > > Replying to [comment:8 annakrat]:
 > > > Replying to [comment:7 mlennert]:
 > > > > Replying to [comment:6 annakrat]:
 > > > > > Please test. It was only problem when using different locale.
 > > > >
 > > > > Right. It +/- works now, i.e. when I chose "screen pixels", I now
 get the correct value in map units below. However, when I change the value
 (i.e. the number of screen pixels), I get a wrong number below: the number
 of screen pixels instead of map units. I have to switch to map units and
 back to screen pixels for the depicted value in map units to be correct
 again.
 > > >
 > > > OK, I committed a new fix in r69579.
 > >
 > > Seems to work great, now ! Thanks.
 > >
 > > Not sure if this is mature enough to backport to release70. You're a
 better judge of that.
 >
 > The only problem is in the settings. The old value should be ignored and
 then new value (0 or 1 is saved). You can test it by manually changing the
 values in the settings file. Since you didn't report any problem with the
 new patch I assume it ignores your saved settings value ("screen pixels"
 or the french version), but please check, you should have now there 0 or 1
 if you saved the settings.

 I'm not sure I saved these settings before. Now, I do have

 {{{
 vdigit;snapping;units;0;value;20
 }}}

 However, when I now try to open the settings dialog in the grass 7.0.5
 digitizer, I get:

 {{{
 Traceback (most recent call last):
   File
 "/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64
 -pc-linux-gnu/gui/wxpython/vdigit/toolbars.py", line 528, in
 OnSettings

 self.settingsDialog = VDigitSettingsDialog(parent =
 self.parent, giface = self._giface)
   File
 "/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64
 -pc-linux-gnu/gui/wxpython/vdigit/preferences.py", line 43,
 in __init__

 self._createGeneralPage(notebook)
   File
 "/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64
 -pc-linux-gnu/gui/wxpython/vdigit/preferences.py", line 168,
 in _createGeneralPage

 self.snappingUnit.SetStringSelection(UserSettings.Get(group
 = 'vdigit', key = "snapping", subkey = 'units'))
   File "/usr/lib/python2.7/dist-
 packages/wx-3.0-gtk2/wx/_core.py", line 13002, in
 SetStringSelection

 return _core_.ItemContainer_SetStringSelection(*args,
 **kwargs)
 TypeError
 :
 String or Unicode type required
 }}}

 so there is an issue of backwards compatibility

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Replying to [comment:9 mlennert]:
 > Replying to [comment:8 annakrat]:
 > > Replying to [comment:7 mlennert]:
 > > > Replying to [comment:6 annakrat]:
 > > > > Please test. It was only problem when using different locale.
 > > >
 > > > Right. It +/- works now, i.e. when I chose "screen pixels", I now
 get the correct value in map units below. However, when I change the value
 (i.e. the number of screen pixels), I get a wrong number below: the number
 of screen pixels instead of map units. I have to switch to map units and
 back to screen pixels for the depicted value in map units to be correct
 again.
 > >
 > > OK, I committed a new fix in r69579.
 >
 > Seems to work great, now ! Thanks.
 >
 > Not sure if this is mature enough to backport to release70. You're a
 better judge of that.

 The only problem is in the settings. The old value should be ignored and
 then new value (0 or 1 is saved). You can test it by manually changing the
 values in the settings file. Since you didn't report any problem with the
 new patch I assume it ignores your saved settings value ("screen pixels"
 or the french version), but please check, you should have now there 0 or 1
 if you saved the settings.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:8 annakrat]:
 > Replying to [comment:7 mlennert]:
 > > Replying to [comment:6 annakrat]:
 > > > Please test. It was only problem when using different locale.
 > >
 > > Right. It +/- works now, i.e. when I chose "screen pixels", I now get
 the correct value in map units below. However, when I change the value
 (i.e. the number of screen pixels), I get a wrong number below: the number
 of screen pixels instead of map units. I have to switch to map units and
 back to screen pixels for the depicted value in map units to be correct
 again.
 >
 > OK, I committed a new fix in r69579.

 Seems to work great, now ! Thanks.

 Not sure if this is mature enough to backport to release70. You're a
 better judge of that.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3057: Problems with Numpy and matplotlib after updating through OSGeo4W

[GRASS GIS]

#3057: Problems with Numpy and matplotlib after updating through OSGeo4W
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by hellik):

 Replying to [comment:10 mlennert]:
 > Any news on this ?

 Still an issue.

 Anything else to test?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Replying to [comment:7 mlennert]:
 > Replying to [comment:6 annakrat]:
 > > Please test. It was only problem when using different locale.
 >
 > Right. It +/- works now, i.e. when I chose "screen pixels", I now get
 the correct value in map units below. However, when I change the value
 (i.e. the number of screen pixels), I get a wrong number below: the number
 of screen pixels instead of map units. I have to switch to map units and
 back to screen pixels for the depicted value in map units to be correct
 again.

 OK, I committed a new fix in r69579.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:2 martinl]:
 > Replying to [ticket:3167 mlennert]:
 > > {{{
 > > createdb -h myRemoteServer testgrass
 > > grass70 -c /data/GRASS/DATA7/nc_spm_08/postgres_test
 > > db.connect driver=pg database="host=myRemoteServer,dbname=testgrass"
 > > }}}
 >
 > did you tried
 >
 > {{{
 > db.connect driver=pg database=testgrass
 > db.login driver=pg database=testgrass host=myRemoteServer
 > }}}
 >

 And if this is how it is supposed to be done, then we need to change the
 man page.

 It just seems a bit redundant to have to indicate driver and database
 twice...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:2 martinl]:
 > Replying to [ticket:3167 mlennert]:
 > > {{{
 > > createdb -h myRemoteServer testgrass
 > > grass70 -c /data/GRASS/DATA7/nc_spm_08/postgres_test
 > > db.connect driver=pg database="host=myRemoteServer,dbname=testgrass"
 > > }}}
 >
 > did you tried
 >
 > {{{
 > db.connect driver=pg database=testgrass
 > db.login driver=pg database=testgrass host=myRemoteServer
 > }}}
 >

 Doesn't work:


 {{{
 rm .grass7/dblogin
 db.connect driver=pg database=testgrass
 db.login driver=pg database=testgrass host=myRemoteServer
 db.tables -p
 DBMI-PostgreSQL erreur de pilote :
 Connection failed.
 FATAL:  la base de données « testgrass » n'existe pas


 DBMI-PostgreSQL erreur de pilote :
 Connection failed.
 FATAL:  la base de données « testgrass » n'existe pas


 ERREUR :Unable to open database 
 }}}

 and with DEBUG=3


 {{{
 D1/3: G_set_program_name(): db.tables
 D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/postgres_test
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D1/3: db_d_init_error(): PostgreSQL
 D3/3: db_get_login(): drv=[pg] db=[testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: ret = 2 : drv=[pg] db=[testgrass] usr=[] pwd=[] host=[], port=[]
 D3/3: db_driver_open_database(): driver=pg database definition =
 'testgrass'
 D3/3: parse_conn: 'testgrass'
 D3/3: db_get_login(): drv=[pg] db=[testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: ret = 2 : drv=[pg] db=[testgrass] usr=[] pwd=[] host=[], port=[]
 D3/3: db_driver_open_database(): host = (null), port = (null), options =
 (null), tty = (null), dbname = testgrass, user = (null), password = (null)
 schema = (null)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:6 annakrat]:
 > Please test. It was only problem when using different locale.

 Right. It +/- works now, i.e. when I chose "screen pixels", I now get the
 correct value in map units below. However, when I change the value (i.e.
 the number of screen pixels), I get a wrong number below: the number of
 screen pixels instead of map units. I have to switch to map units and back
 to screen pixels for the depicted value in map units to be correct again.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by martinl):

 Replying to [ticket:3167 mlennert]:
 > {{{
 > createdb -h myRemoteServer testgrass
 > grass70 -c /data/GRASS/DATA7/nc_spm_08/postgres_test
 > db.connect driver=pg database="host=myRemoteServer,dbname=testgrass"
 > }}}

 did you tried

 {{{
 db.connect driver=pg database=testgrass
 db.connect driver=pg database=testgrass host=myRemoteServer
 }}}

 ? Martin

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 {{{
 g.gisenv set=DEBUG=3
 db.tables -p
 D1/3: G_set_program_name(): db.tables
 D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/postgres_test
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D1/3: db_d_init_error(): PostgreSQL
 D3/3: db_get_login(): drv=[pg] db=[host=myRemoteServer,dbname=testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: login file does not exist
 D3/3: db_driver_open_database(): driver=pg database definition =
 'host=myRemoteServer,dbname=testgrass'
 D3/3: parse_conn: 'host=myRemoteServer,dbname=testgrass'
 D3/3: token 0 : host=myRemoteServer
 D3/3: token 1 : dbname=testgrass
 D3/3: db_get_login(): drv=[pg] db=[host=myRemoteServer,dbname=testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: login file does not exist
 D3/3: db_driver_open_database(): host = (null), port = (null), options =
 (null), tty = (null), dbname = testgrass, user = (null), password = (null)
 schema = (null)
 }}}


 {{{
 db.login driver=pg database=host=myRemoteServer,dbname=testgrass
 db.tables -pD1/3: G_set_program_name(): db.tables
 D2/3: G_file_name(): path = /data/GRASS/DATA7/nc_spm_08/postgres_test
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D2/3: dbDbmscap(): opendir
 [/data/home/mlennert/SRC/GRASS/grass70_release/dist.x86_64-pc-linux-
 gnu/driver/db/]
 D1/3: db_d_init_error(): PostgreSQL
 D3/3: db_get_login(): drv=[pg] db=[host=myRemoteServer,dbname=testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: ret = 2 : drv=[pg] db=[host=myRemoteServer,dbname=testgrass] usr=[]
 pwd=[] host=[], port=[]
 D3/3: db_driver_open_database(): driver=pg database definition =
 'host=myRemoteServer,dbname=testgrass'
 D3/3: parse_conn: 'host=myRemoteServer,dbname=testgrass'
 D3/3: token 0 : host=myRemoteServer
 D3/3: token 1 : dbname=testgrass
 D3/3: db_get_login(): drv=[pg] db=[host=myRemoteServer,dbname=testgrass]
 D3/3: read_file(): DB login file = 
 D3/3: ret = 2 : drv=[pg] db=[host=myRemoteServer,dbname=testgrass] usr=[]
 pwd=[] host=[], port=[]
 D3/3: db_driver_open_database(): host = (null), port = (null), options =
 (null), tty = (null), dbname = testgrass, user = (null), password = (null)
 schema = (null)
 }}}

 So the host name gets lost somewhere on the way.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Please test. It was only problem when using different locale.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 In [changeset:"69578" 69578]:
 {{{
 #!CommitTicketReference repository="" revision="69578"
 GUI/vdigit: fix snapping units, see #2848
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 7.0.5 release planning - blocker !

[Moritz Lennert]

On 26/09/16 14:59, Moritz Lennert wrote:

On 26/09/16 14:41, Moritz Lennert wrote:

On 24/09/16 12:36, Martin Landa wrote:

Hi,

2016-09-18 16:21 GMT+02:00 Martin Landa :

cool, count with my support please. Ma


since RC2 has been released on Sunday 18/9, the final release 7.0.5
should be out ~tomorrow. Any objections?


It would be great to see https://trac.osgeo.org/grass/ticket/3057 solved
as this seems to be an annoying issue in MS Windows.

Other than that, I'm +1 for releasing.


Except for this issue:

https://lists.osgeo.org/pipermail/grass-user/2016-September/075160.html

I'm currently looking at this, but I seem to be able to confirm: remote
database access doesn't work correctly. This is definitely a blocker.

I'll write up a bug report once I have a reproducible example.


https://trac.osgeo.org/grass/ticket/3167

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

[GRASS-dev] [GRASS GIS] #3167: db.connect: connection to remote database does not work

[GRASS GIS]

#3167: db.connect: connection to remote database does not work
---+-
 Reporter:  mlennert   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  blocker|  Milestone:  7.0.5
Component:  Database   |Version:  unspecified
 Keywords:  postgresql db.connect  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 In a freshly compiled 70release:

 {{{
 createdb -h myRemoteServer testgrass
 grass70 -c /data/GRASS/DATA7/nc_spm_08/postgres_test
 db.connect driver=pg database="host=myRemoteServer,dbname=testgrass"
 > db.tables -p
 DBMI-PostgreSQL erreur de pilote :
 Connection failed.
 FATAL:  la base de données « testgrass » n'existe pas


 DBMI-PostgreSQL erreur de pilote :
 Connection failed.
 FATAL:  la base de données « testgrass » n'existe pas


 ERREUR :Unable to open database
 

Re: [GRASS-dev] 7.0.5 release planning - blocker !

[Moritz Lennert]

On 26/09/16 14:41, Moritz Lennert wrote:

On 24/09/16 12:36, Martin Landa wrote:

Hi,

2016-09-18 16:21 GMT+02:00 Martin Landa :

cool, count with my support please. Ma


since RC2 has been released on Sunday 18/9, the final release 7.0.5
should be out ~tomorrow. Any objections?


It would be great to see https://trac.osgeo.org/grass/ticket/3057 solved
as this seems to be an annoying issue in MS Windows.

Other than that, I'm +1 for releasing.


Except for this issue:

https://lists.osgeo.org/pipermail/grass-user/2016-September/075160.html

I'm currently looking at this, but I seem to be able to confirm: remote 
database access doesn't work correctly. This is definitely a blocker.


I'll write up a bug report once I have a reproducible example.

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

Re: [GRASS-dev] 7.0.5 release planning

[Moritz Lennert]

On 24/09/16 12:36, Martin Landa wrote:

Hi,

2016-09-18 16:21 GMT+02:00 Martin Landa :

cool, count with my support please. Ma


since RC2 has been released on Sunday 18/9, the final release 7.0.5
should be out ~tomorrow. Any objections?


It would be great to see https://trac.osgeo.org/grass/ticket/3057 solved 
as this seems to be an annoying issue in MS Windows.


Other than that, I'm +1 for releasing.

Moritz

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

Re: [GRASS-dev] [GRASS GIS] #3057: Problems with Numpy and matplotlib after updating through OSGeo4W

[GRASS GIS]

#3057: Problems with Numpy and matplotlib after updating through OSGeo4W
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by mlennert):

 Any news on this ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2848: g.gui.vdigit: snapping distance seems to only be defined in map units, not screen pixels

[GRASS GIS]

#2848: g.gui.vdigit: snapping distance seems to only be defined in map units, 
not
screen pixels
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Can anyone else confirm this issue ?
 I'm still seeing it.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3166: Parallelization with tiling for grass.script

[GRASS GIS]

#3166: Parallelization with tiling for grass.script
--+--
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  script, parallel
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by huhabla):

 I think we can adapt your implementation to use the
 MultiModule/ParallelModuleQueue approach. The MultiModule class supports
 the execution of a stack of any GRASS modules in a temporary region
 environment. Hence instead of implementing a different module executor,
 you can use pygrass Module and MultiModule to define the processing. Use
 the ParallelModuleQueue to run the stacks in parallel. You have access to
 all executed modules and can investigate errors, stdout, stderr and
 input/output options.

 Hence the TiledWorkflow class would accept MutliModule objects and will
 use the ParallelModuleQueue internally to run the module stacks in
 parallel. What do you think?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2318: G7: t.* modules unclear -s flag

[GRASS GIS]

#2318: G7: t.* modules unclear -s flag
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.2.0
 Component:  Temporal |Version:  svn-releasebranch70
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * milestone:  7.0.5 => 7.2.0


Comment:

 IIUC, this should not go into 7.0.5.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2902: i.segment.hierarchical: Execution of subprocesses was not successful

[GRASS GIS]

#2902: i.segment.hierarchical: Execution of subprocesses was not successful
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.5
 Component:  Addons  |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  i.segment.hierarchical GridModule
   CPU:  |  subprocesses
  Unspecified|   Platform:  Unspecified
-+-
Changes (by mlennert):

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


Comment:

 As the original bug is fixed and I have trouble reproducing the second
 issue reliably, I'm closing this bug and will open another one if needed.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Margherita Di Leo]

Hi,

On Fri, Sep 23, 2016 at 12:00 AM, Markus Neteler  wrote:

> Hi,
>
> in order to not hinder the addition of important new flags/parameters
> to modules while keeping things optionally easy it would be good to
> implement some expert mode to the parser.
>
> The flags and parameters for advanced users should be hidden by
> default (maybe by using an extra definition in order to "tag" them in
> the source code). Then e.g. by setting a variable they would become
> visible in the help text and GUI.
> Probably they should be always accepted when being invoked.
>

 This makes sense to me. If I type name.module --help and the command line
yield too long a list of parameters, I normally prefer reading it on the
manual page, where it is more clear, and I find extremely useful the usage
examples of the flags. I don't find it very informative to list all the
flags in command line, even the less used. There could be for example a
--ext-help for extended help display. So for example, typing only --help
would list only most used options and would end with "type --ext-help for
extended help" or something like that.

My 2 c

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

Re: [GRASS-dev] [GRASS GIS] #3166: Parallelization with tiling for grass.script

[GRASS GIS]

#3166: Parallelization with tiling for grass.script
--+--
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  script, parallel
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mlennert):

 Wow, this looks great !

 Could you just explain the relation / difference between this and the
 GridModule in pygrass ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Blumentrath, Stefan]

Hi,

I have been struggling with similar issues and solved them by writing a 
GRASS_BATCH_JOB script that I execute in parallel in different mapsets.
Thus, the approach Markus and Sören sketch looks very useful to me (even for 
people who are not on HPC).

Do you have more options / flags in mind than the region settings? Just asking 
to get a better idea about the amount of how module complexity may increase 
with the changes you plan?

If it is only region settings per module-call that should not be overwhelming 
for users. E.g., the QGIS-GRASS plugin (and I guess Processing too) has a 
button for «use region of this map» for every command with raster input, which 
is pointing in this direction (though not as sophisticated as your solution). 
And QGIS aimed at simplifying the interaction with GRASS analysis ;-).

In order to not blowing up the manual too much, one might write a compact 
standard description that points to g.region or a central, more detailed 
description of the new options, which will be the same for every module that 
uses them, would not they?

After you explained a bit more what you are after I do not really see a problem 
with this. In fact I am very positive!
But I have to admit that I did not understand the difference between 
--raster-region and --vector-region. Are you planning to implement some 
vector-tiles solution?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: 26. september 2016 04:28
To: Markus Neteler 
Cc: GRASS developers list ; Markus Metz 

Subject: Re: [GRASS-dev] Adding an expert mode to the parser


On Sun, Sep 25, 2016 at 3:49 PM, Markus Neteler 
> wrote:
when doing each job in its own mapset and reintegrate it in a single
target mapset as if able to process then in parallel in one mapset by
simply specifying the respective region to the command of interest.
Yes, different from the current paradigm and not for G7.

I think, we can accommodate this behavior in G7. In fact, each command can run 
with a separate region even now. It can set it on its own, take it from 
GRASS_REGION or WIND_OVERRIDE. But if you are talking about automatic patching, 
that's of course different.


But my original comment was targeted at the increasing number of
module parameters and how to handle that (with some new HPC related
idea as an example).

I think we need to talk about specific use cases and decide based on that. For 
some, Advanced or HPC tab might be enough. Some others might be better 
addressed by a specific global options like what Soeren just suggested (in the 
style of --overwrite).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 7.0.5 release planning

[Markus Metz]

On Sat, Sep 24, 2016 at 12:36 PM, Martin Landa  wrote:
> Hi,
>
> 2016-09-18 16:21 GMT+02:00 Martin Landa :
>> cool, count with my support please. Ma
>
> since RC2 has been released on Sunday 18/9, the final release 7.0.5
> should be out ~tomorrow. Any objections? @MarkusM: is there anything
> waiting to be backported regarding your recent fixes?

Nothing to be backported from my side, v.edit tool=merge works now as expected.

Markus M

>
> Thanks for collaboration, Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev