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):

 Yes, I would like to reconcile the two APIs or implementations (or both).
 At this point, I still see too many differences.

 Replying to [comment:4 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 API with for-loop is actually based on the case where the user wants
 the for loop like this one:

 {{{
 #!python
 for i in range(0, 5):
 gs.run_command('r.module', num=i)
 gs.mapcalc(expr, num=i)
 }}}

 I had code like this and I wanted to parallelize the individual loop runs
 which are independent. So I just come up with the following API which is
 not changing much in the main part of the code:

 {{{
 #!python
 workflow = SeriesWorkflow()  # currently called ModuleCallList
 for i in range(0, 5):
 workflow.run_command('r.module', num=i)
 workflow.mapcalc(expr, num=i)
 workflow.execute()
 }}}

 The Python functions I used in the background have some problems with
 interrupting and failed subprocesses but they handle well a pool of
 subprocess so that there is always the given number of processes running
 (so there can be one really slow process but the others are just running
 in the mean time).

 Then I had a different case, where I didn't have any loop but I needed the
 tiling. The following API emerged from that:

 {{{
 #!python
 for namer, workflow in TiledWorkflow(width=100, height=100):
 name = namer.name('rast', i)
 workflow.run_command('r.module', num=name)
 workflow.mapcalc(expr, num=name)
 workflow.execute()
 }}}

 This was of course before r69507, but the reasons for similar API are
 still there because the non-tiled workflow just has the loop anyway (if
 desired). One argument against current `TiledWorkflow` would actually be
 that we want the API to be different from the case where the loop is
 actually desired by the user.

 > 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 user (at least me) uses variables anyway. With the `SeriesWorkflow`
 case, user names the outputs as needed because all are preserved. With
 `TiledWorkflow` the variables needs to be assigned with the help of the
 `TiledWorkflow`, so some work is required but not that much.

 > 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.

 I don't think it is as simple as replacing the names which is of course
 possible only with PyGRASS, not grass.script. The naming step in
 `TiledWorkflow` simply adds maps for patching. This has potential to
 handle the case for r.mapcalc expressions as well as ''some'' basename
 usages like from r.texture. I don't have this implemented, but the user
 could also not include some outputs for patching and mark them for removal
 instead.

 > > 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. ;)

 Right. I guess my point is that parallel.py mostly relies on higher level
 functions from Python multiprocessing and on grass.script which is itself
 simple. Furthermore, parallel.py is more than just `TiledWorkflow`,
 although that's the longest and most complicated part. The parallel.py's
 design is to cover as many cases as possible with minimal code and the
 cost is that user needs to do something special time to time like the
 naming step for `TiledWorkflow` or the use of somehow wrapper functions
 instead of the real ones (applies to both `SeriesWorkflow` and
 `TiledWorkflow`). However, I think that `MultiModule` and others are much
 more robust at this point. parallel.py's only hope for being robust is
 that it is simple enough to become robust one day.

 I hope this clarifies a little bit more where I'm coming from. I know I
 was not specific in that private email week ago.

--
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] #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 annakrat):

 I still can't reproduce it, even with wxpython 3.0.2.0. First try using
 different font, but I don't think that would help. Next try to apply this
 change and recompile:

 {{{
 Index: animation/utils.py
 ===
 --- animation/utils.py  (revision 69577)
 +++ animation/utils.py  (working copy)
 @@ -245,7 +245,7 @@

  def RenderText(text, font, bgcolor, fgcolor):
  """Renderes text with given font to bitmap."""
 -dc = wx.MemoryDC()
 +dc = wx.MemoryDC(wx.EmptyBitmap(20, 20))
  dc.SetFont(font)
  w, h = dc.GetTextExtent(text)
  bmp = wx.EmptyBitmap(w + 2, h + 2)

 }}}

 I hope this could help, otherwise I have no idea.

--
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:  closed
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:  fixed|   Keywords:  vector, digitize
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by annakrat):

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


Comment:

 OK, backported, tested again and hopefully fixed now.

--
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:"69595" 69595]:
 {{{
 #!CommitTicketReference repository="" revision="69595"
 GUI/vdigit: fix snapping units, see #2848 (merge from trunk r69578,
 r69579, r69580)
 }}}

--
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:"69594" 69594]:
 {{{
 #!CommitTicketReference repository="" revision="69594"
 GUI/vdigit: fix snapping units, see #2848 (merge from trunk r69578,
 r69579, r69580)
 }}}

--
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

[Vaclav Petras]

On Tue, Sep 27, 2016 at 5:38 PM, Sören Gebbert  wrote:

> However, the correct use of GRASS_REGION is still unclear to me.


There is a function in grass.script [1] which can generate the right
string. It calls g.region with -u, so you can modify the region with
g.region, but without actually changing it. Then you just set the
environmental variable for the process. If you anyway control the
environment for the subprocess, I think, there is not much difference
between GRASS_REGION and WIND_OVERRIDE expect for a file and length of
command line.

If the g.region code is moved to library (there might be some modules which
would benefit from it) and parser accepts standard options with values,
then parser could just set this variable in the same way it sets
GRASS_OVERWRITE (to keep parser and rest of lib/gis separate - although
this might not be an option anyway if it needs to use the g.region
functions).

[1] https://grass.osgeo.org/grass70/manuals/libpython/
script.html#script.core.region_env
___
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 Tue, Sep 27, 2016 at 5:01 PM, Sören Gebbert  wrote:

> From my understanding, the GRASS_REGION environmental variable is
> supported by G_get_window() [1]. However, most raster modules
> uses  Rast_window_rows() and Rast_window_cols() to get the current
> computational region rows and cols. Hence, setting GRASS_REGION will not
> affect most of the raster modules.
>

This would be a buggy behavior but I think it is not the case. All 2D
raster window functions use Rast__init_window() [2] which calls
G__init_window() [3] which uses G_get_window() [4]. I'm not sure about 3D
rasters but I think WIND_OVERRIDE worked for me. Display modules seems to
accept GRASS_REGION because that's actually how it is used in code. Vector
modules probably just use the G_ function.

Vaclav

[2]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/window.c?rev=69586
[3]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/set_window.c?rev=69586#L24
[4]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/set_window.c?rev=69586#L70



>
> Best regards
> Soeren
>
> [1] https://trac.osgeo.org/grass/browser/grass/trunk/lib/
> gis/get_window.c?rev=69586#L30
>
___
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

[Sören Gebbert]

Hi,

> On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert <
>> soerengebb...@googlemail.com> wrote:
>>
>>> >r.mapclac --raster-region= --north= --south= --west= --east= --res=
 >--ewres= --nsres= --vect-region --raster-align= ...

>>>
>> I like this in the sense that if the region setting for the module is
>> something which should be managed by these extra options, then they should
>> be managed in parser, rather than introduced one by one for individual
>> modules.
>>
>> But how is this different from using GRASS_REGION? Convenience of 
>> --raster-region=?
>> Better syntax than environmental variable?
>>
>
> From my understanding, the GRASS_REGION environmental variable is
> supported by G_get_window() [1]. However, most raster modules
> uses  Rast_window_rows() and Rast_window_cols() to get the current
> computational region rows and cols. Hence, setting GRASS_REGION will not
> affect most of the raster modules.
>

While inspecting the raster and libgis code i realized that the code that
initializes the input and output raster window eventually calls
G_get_window(). Hence, the GRASS_REGION environmental variable will have an
effect on  Rast_window_rows() and Rast_window_cols(). However, the correct
use of GRASS_REGION is still unclear to me.
___
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

[Sören Gebbert]

Hi,

2016-09-26 4:16 GMT+02:00 Vaclav Petras :

>
> On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert <
> soerengebb...@googlemail.com> wrote:
>
>> >r.mapclac --raster-region= --north= --south= --west= --east= --res=
>>> >--ewres= --nsres= --vect-region --raster-align= ...
>>>
>>
> I like this in the sense that if the region setting for the module is
> something which should be managed by these extra options, then they should
> be managed in parser, rather than introduced one by one for individual
> modules.
>
> But how is this different from using GRASS_REGION? Convenience of 
> --raster-region=?
> Better syntax than environmental variable?
>

>From my understanding, the GRASS_REGION environmental variable is supported
by G_get_window() [1]. However, most raster modules
uses  Rast_window_rows() and Rast_window_cols() to get the current
computational region rows and cols. Hence, setting GRASS_REGION will not
affect most of the raster modules.

Best regards
Soeren

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/get_window.c?rev=69586#L30
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

[GRASS GIS]

#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (by huhabla):

 This issue should be fixed in r69586.

--
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] #3168: Behavior of t.register when r.timestamp was used

[GRASS GIS]

#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (by huhabla):

 This is indeed a strange error. I will fix the register method to use only
 the time stamp from the spatial database, when no time stamp was provided
 on the command line or in the input file.

 One reason why this error happened is that r.sim.water creates a relative
 time stamp and you specified an absolute time stamp on the command line.
 Hence, the wrong time stamp conversion.

 Interesting error case that i did not 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:17 mlennert]:
 > Then things look pretty good for me. I just want to make sure we don't
 create a regression if we backport this fix this late before the release
 of 7.0.5.

 I understand, thanks for testing. I will backport later today.

--
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:16 annakrat]:
 > Replying to [comment:15 mlennert]:
 > > Replying to [comment:14 annakrat]:
 > > > Replying to [comment:13 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 ?).
 > > > >
 > > >
 > > > That's correct, 'units' is the old name kept there for backwards
 compatibility, 'unit' is the new one (0 is screen pixels, 1 is map units).
 > >
 > > Yes, I understand that, but if 1 is map units, then why does the line
 contain 'units;screen pixels' and 'unit;1' ? Shouldn't it be 'units;map
 units' ?
 >
 > I don't care about the value of 'units' anymore, I am not trying to set
 it, I just kept them there so that the settings file can be read without
 error in old versions.

 Then things look pretty good for me. I just want to make sure we don't
 create a regression if we backport this fix this late before the release
 of 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] #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:15 mlennert]:
 > Replying to [comment:14 annakrat]:
 > > Replying to [comment:13 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 ?).
 > > >
 > >
 > > That's correct, 'units' is the old name kept there for backwards
 compatibility, 'unit' is the new one (0 is screen pixels, 1 is map units).
 >
 > Yes, I understand that, but if 1 is map units, then why does the line
 contain 'units;screen pixels' and 'unit;1' ? Shouldn't it be 'units;map
 units' ?

 I don't care about the value of 'units' anymore, I am not trying to set
 it, I just kept them there so that the settings file can be read without
 error in old versions.

--
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] #3169: use external shapelib

[GRASS GIS]

#3169: use external shapelib
--+-
  Reporter:  opoplawski   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by opoplawski):

 See also issue #1318

--
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:14 annakrat]:
 > Replying to [comment:13 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 ?).
 > >
 >
 > That's correct, 'units' is the old name kept there for backwards
 compatibility, 'unit' is the new one (0 is screen pixels, 1 is map units).

 Yes, I understand that, but if 1 is map units, then why does the line
 contain 'units;screen pixels' and 'unit;1' ? Shouldn't it be 'units;map
 units' ?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3169: use external shapelib

[GRASS GIS]

#3169: use external shapelib
-+-
 Reporter:  opoplawski   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Default  |Version:  7.0.4
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Is there any reason at this point to not compile against an external
 shapelib?

--
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

[Vaclav Petras]

On Mon, Sep 26, 2016 at 5:50 PM, Vaclav Petras  wrote:

> 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?


Additionally, the label and description is also for the module itself, so
when we have label, we don't need to show description, that's -1 line for
r.slope.aspect. Then we can remove keywords, that's -3 lines. Then we have
the standard/long flags. (These might be similar to the general options
from `ogr2ogr --help-general` which Madi posted.) They are the same all the
time, except for --o, so that's -4 or -3 for the old ones (depending on
module) and -2 for the recently added flags (--qq --ui). They still can be
in `Usage:` section or they may not. There is also an empty line at the
beginning, we can remove it as well because don't go for beauty and the
`Description:` title is also not necessary, so we could remove that as
well, that's -2 lines. That would be 12 lines total. (I have 55 lines in
the terminal windows I'm using right now, so 12 seems to be quite a lot).

In GUI or even in the manual, we could put the standard/long flags to a
separate section as well.

> r.slope.aspect --help

Description:
 Generates raster maps of slope, aspect, curvatures and partial derivatives
from an elevation raster map.
 Aspect is calculated counterclockwise from east.

Keywords:
 raster, terrain, aspect, slope, curvature

Usage:
 r.slope.aspect [-a] elevation=name [slope=name] [aspect=name]
   [format=string] [precision=string] [pcurvature=name] [tcurvature=name]
   [dx=name] [dy=name] [dxx=name] [dyy=name] [dxy=name] [zscale=value]
   [min_slope=value] [--overwrite] [--help] [--verbose] [--quiet] [--ui]

Flags:
  -a   Do not align the current region to the raster elevation map
 --o   Allow output files to overwrite existing files
 --h   Print usage summary
 --v   Verbose module output
 --q   Quiet module output
 --qq  Super quiet module output
 --ui  Force launching GUI dialog
___
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]

On Tue, Sep 27, 2016 at 9:15 AM, Margherita Di Leo 
wrote:

> Hi,
>
> On Tue, Sep 27, 2016 at 7:13 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> 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.
>
>
> +1.
>


For inspiration, looking at gdal: http://www.gdal.org/ogr2ogr.html

$ ogr2ogr --help-general
Generic GDAL/OGR utility command options:
[...]

$ ogr2ogr --help
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
   [-select field_list] [-where restricted_where]
   [-progress] [-sql ] [-dialect dialect]
   [-preserve_fid] [-fid FID]
   [-spat xmin ymin xmax ymax] [-geomfield field]
   [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]
   [-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]
   dst_datasource_name src_datasource_name
   [-lco NAME=VALUE] [-nln name] [-nlt type] [-dim
2|3|layer_dim] [layer [layer ...]]

Advanced options :
[...]
Note: ogr2ogr --long-usage for full help.

$ ogr2ogr --long-usage
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
  [...]

Advanced options :
   [...]

 -f format_name: output file format name, possible values are:
  [...]



-- 
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] #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:13 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 ?).
 >

 That's correct, 'units' is the old name kept there for backwards
 compatibility, 'unit' is the new one (0 is screen pixels, 1 is map units).

 > 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.

 It is broken in GRASS70, the point is it shouldn't give you any error
 caused by the changes in the new settings file.
 >
 > When I then open trunk, it gives me the default settings of 10 screen
 pixels.
 That's correct. So I would say it behaves as I would expect.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

[GRASS GIS]

#3168: Behavior of t.register when r.timestamp was used
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.0
Component:  Temporal |Version:  svn-trunk
 Keywords:  t.create, t.register, r.timestamp,   |CPU:  Unspecified
  G_write_raster_timestamp   |
 Platform:  Unspecified  |
-+-
 I'm trying to figure out what is the right behavior and usage of
 t.register in case when the raster map already has a "simple GRASS" time
 stamp (managed e.g. by `r.timestamp`).

 For example, `r.sim.water` with `-t` produces time series which has time
 stamps from `G_write_raster_timestamp()`. The time stamps are relative.

 Later, when you create a temporal dataset using t.create and set absolute
 time and use `t.register` to register the map or maps providing the start
 time and increment, you get an error saying that the time and date
 provided as start cannot be converted to integer.

 Here is the code to reproduce it:

 {{{
 #!bash
 g.region s=0 w=0 n=100 e=100 -p res=10
 r.surf.fractal elevation
 r.slope.aspect elevation=elevation dx=dx dy=dy
 r.sim.water el=elevation dx=dx dy=dy depth=depth -t
 t.create output=depth type=strds temporaltype=absolute title="Depths"
 description="Time series of depths from r.sim.water
 t.register input=depth maps=depth.02 start="2015-01-01 00:01:00"
 }}}

 And this is the error:

 {{{
 ERROR: invalid literal for int() with base 10: '2015-01-01 00:01:00'
 }}}

 It comes from:

 {{{
 #!python
 if ttype == "absolute":
 ...
 else:
 start_time = int(start)  # here
 }}}

 The time stamp is read from the spatial database in
 [source:grass/trunk/lib/python/temporal/register.py#L284 register.py]:

 {{{
 #!python
 if not is_in_db:
 map.read_timestamp_from_grass()
 }}}

 The condition doesn't depend on the input parameters to `t.register` and
 the behavior seems to be unexpected from the user point of view (plus of
 course there should be no low-level error like this one).

--
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

[Newcomb, Doug]

+1

On Mon, Sep 26, 2016 at 6:11 PM, Vaclav Petras  wrote:

>
> 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
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
As a federal employee, my email may be subject to FOIA request.
___
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

[Rainer M Krug]

Moritz Lennert  writes:

> 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:

Everybody is so used to using --help (or -h) that I don't think that an
--simple-help would do any good.

Instead, possibly -hh (as in -vv for more verbose) and mention this in
the first line of the help?

This would open even for -hhh if most advanced options are there.

Concerning --help, this should possibly change to displaying the basic
-h

Rainer

>
>> 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
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
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:10 mlennert]:
 > The issue arises when some of the fields are empty, as for usr and pwd
 in my example. Anything from that point on is ignored. When I set a
 username and password with db.login, my db.tables example works like a
 charm.
 >
 > See [http://stackoverflow.com/questions/1508754/how-do-i-parse-out-the-
 fields-in-a-comma-separated-string-using-sscanf-while-sup here] for a
 discussion of the issue. Would using strtok be an alternative, here ? Or
 better yet: G_tokenize() ?

 I've attached a proof-of-concept patch that solves the problem for me, but
 it hardcodes the number of tokens. I don't know what forms login strings
 can potentially take, so this definitely needs to be revised to take into
 account different scenarios.

--
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
--+---
Changes (by mlennert):

 * Attachment "dbmi_base_login.diff" added.

 very crude patch to show path to solution

--
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 Tue, Sep 27, 2016 at 7:13 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> 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.


+1.


> 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...


+1 also here :-)

>
>
> 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...
>

+1000 :-)
So this afternoon at the GRASS meetup [
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016] we can give
a meaningful example on how users can contribute to GRASS without coding
:-)

Cheers,
madi

>
> 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
>



-- 
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] #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 issue arises when some of the fields are empty, as for usr and pwd in
 my example. Anything from that point on is ignored. When I set a username
 and password with db.login, my db.tables example works like a charm.

 See [http://stackoverflow.com/questions/1508754/how-do-i-parse-out-the-
 fields-in-a-comma-separated-string-using-sscanf-while-sup here] for a
 discussion of the issue. Would using strtok be an alternative, here ? Or
 better yet: G_tokenize() ?

--
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):

 Getting closer:

 The issue seems to be in the reading of the dblogin file.

 My file contains;

 {{{
 pg|testgrass|||myRemoteHost|
 }}}

 But the debug message show:


 {{{
 D3/3: read_file(): DB login file = 
 D3/3: ret = 2 : drv=[pg] db=[testgrass] usr=[] pwd=[] host=[], port=[]
 }}}

 Looking at the sscanf call that reads the data from the file (in
 lib/db/dbmi_base/login.c, line 118, I see:


 {{{
 ret = sscanf(buf, "%[^|]|%[^|]|%[^|]|%[^|]|%[^|]|%[^\n]",
  dr, db, usr, pwd, host, port);
 }}}

 Somehow this doesn't seem to read the line as it should...

--
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):

 BTW: I get the same errors in trunk.

--
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:4 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
 > > }}}
 > >
 >

 I just noticed that the first sentence with the most important information
 is missing:

 Yes, I tried, but it didn't make a difference. Exact same error as before
 and DEBUG=3 gives me:

 D3/3: db_driver_open_database(): host = (null), port = (null), options =
 (null), tty = (null), dbname = testgrass, user = (null), password = (null)
 schema = (null)

 > 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:5 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 ?

 Replying to myself: this is when I use db.connect without 'host=' in the
 database string. When I use 'host=', I get:

 DB_DRIVER: pg
 DB_DATABASE: host=myRemoteHost,dbname=testgrass

--
Ticket URL: 
GRASS GIS 

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