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

[Vaclav Petras]

On Wed, Sep 28, 2016 at 4:35 PM, Markus Metz 
wrote:

> On Tue, Sep 27, 2016 at 5:55 PM, Vaclav Petras 
> wrote:
> >
> > 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).
>
> +1


Done in r69602. I limited the changes to the usage() function (G_usage()
backend). The behavior is driven by 3 variables which can become function
parameters in the future. For now, full description can be found in the
using man or g.manual commands. Some --full-help can be implemented if
desired. Related to that, I did not preserved the functionality of
--help-text, this can be fixed as well.

Next step would be ensuring that each module has its label (or description)
short enough that it fits into one line (72 characters?). Similarly, each
option and flag should have label (or description) which fits on one line
considering that we need some space for flag, option name and horizontal
spacing.

Anyway, here is the state before:

> r.slope.aspect --help 2>&1 | wc
 48 2552137
> v.in.lidar --help 2>&1 | wc
 72 4623634

And after:

> r.slope.aspect --help 2>&1 | wc
 32 1941620
> v.in.lidar --help 2>&1 | wc
 43 2422002

Please test,
Vaclav


https://trac.osgeo.org/grass/changeset/69602
___
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,

[snip]
> >
> > As an example, when aiming at processing all Sentinel-2 tiles
> > globally, we speak about currently 73000 scenes * up-to-16 tiles along
> > with global data, analysis on top of other global data is more complex
> > 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.
>
> from our common experience, I would say that creating separate mapsets
> is a safety feature. If anything goes wrong with that particular
> processing chain, cleaning up is easy, simply delete this particular
> mapset and run the job again, if possible on a different host/node
> (assuming that failed jobs are logged). Anyway, I would be surprised
> if the overhead of opening a separate mapset is measurable when
> processing all Sentinel-2 tiles globally. Reintegration into a single
> target mapset could cause problems with regard to IO saturation, but
> in a HPC environment temporary data always need to be copied to a
> final target location at some stage. The HPC system you are using now
> is most probably quite different from the one we used previously, so
> this is a lot of guessing, particularly about the storage location of
> temporary data (no matter if it is the same mapset or a separate
> mapset).
>

Imagine you have a tool that is able to distribute the processing of a
large time series of satellite images across a cluster. Each node in the
cluster should process a stack of r.mapcalc, r.series or r.neighbors
commands in a local temporary mapset, that gets later merged into a single
one. A single stack of commands may have hundreds of jobs that will run in
a single temporary mapset. In this scenario you need separate region
settings for each command in the stack, because of the different spatial
extents of the satellite images. The size of the stack depends on the size
of the time series (number of maps) and the number of available nodes.

Having region setting options in the parser will make the implementation of
such an approach much easier. Commands like t.rast.algebra and
t.rast.neighbors will directly benefit from a region parser option,
allowing the parallel processing of satellite image time series on a
multi-core machine.

Best regards
Soeren


> To be continued in a GRASS+HPC thread?
>
> Markus M
>
> >
> > 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'm fine to archive this question for now, it will likely come up
> > again in the future.
> >
> > markusN
> ___
> 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 7.2 planning

[Markus Neteler]

Sorry for the mixup.

So, we should also go on with 7.2 and target a soonish release.

Yet open issue are here, some will be postponed to 7.2.1...:

https://trac.osgeo.org/grass/query?status=new=assigned=reopened=7.2.0=type=priority

And please all update
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Markus
___
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 Neteler]

New attempt in the right thread, sorry.

Hi,

the new db.login blocker got solved, thanks.
The question is if we need a new RC or go ahead?

Any objections to go ahead and release without new RC?

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

Re: [GRASS-dev] grass 7.2 planning

[Martin Landa]

Hi,

2016-09-28 23:20 GMT+02:00 Markus Neteler :
> the new db.login blocker for solved, thanks.
> The question is if we need a new RC or go ahead?
>
> Any objections to go ahead and release without new RC?

I guess you are referring to 7.0.5 (this thread is about 7.2).
Regarding 7.0.5 I would go ahead without any new RC2. 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

Re: [GRASS-dev] grass 7.2 planning

[Markus Neteler]

Hi,

the new db.login blocker for solved, thanks.
The question is if we need a new RC or go ahead?

Any objections to go ahead and release without new RC?

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

[Markus Metz]

On Sun, Sep 25, 2016 at 9:49 PM, Markus Neteler  wrote:
> On Fri, Sep 23, 2016 at 11:30 PM, Markus Metz
>  wrote:
>> On Fri, Sep 23, 2016 at 11:22 PM, Markus Neteler  wrote:
>>> On Fri, Sep 23, 2016 at 11:05 PM, Markus Metz
>>>  wrote:
 On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler  wrote:
>>> ...
 Your motivation is to provide a specialized CLI interface for HPC
 processing?
>>>
>>> No, not the case.
>>>
 We used GRASS with HPC processing for years and the
 problems we faced were causes by the HPC hardware and software
 infrastructure, not by GRASS. What exactly is the problem with using
 GRASS and HPC processing?
>>>
>>> There is no problem. There is just the issue that with an increasing
>>> amount of additions (e.g. maybe the need to provide region/resolution
>>> to individual modules for independent parallel processing without the
>>> overhead of always opening a new mapset)
>>
>> Getting closer it seems. Can you quantify "the overhead of always
>> opening a new mapset"?
>
> As an example, when aiming at processing all Sentinel-2 tiles
> globally, we speak about currently 73000 scenes * up-to-16 tiles along
> with global data, analysis on top of other global data is more complex
> 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.

from our common experience, I would say that creating separate mapsets
is a safety feature. If anything goes wrong with that particular
processing chain, cleaning up is easy, simply delete this particular
mapset and run the job again, if possible on a different host/node
(assuming that failed jobs are logged). Anyway, I would be surprised
if the overhead of opening a separate mapset is measurable when
processing all Sentinel-2 tiles globally. Reintegration into a single
target mapset could cause problems with regard to IO saturation, but
in a HPC environment temporary data always need to be copied to a
final target location at some stage. The HPC system you are using now
is most probably quite different from the one we used previously, so
this is a lot of guessing, particularly about the storage location of
temporary data (no matter if it is the same mapset or a separate
mapset).

To be continued in a GRASS+HPC thread?

Markus M

>
> 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'm fine to archive this question for now, it will likely come up
> again in the future.
>
> markusN
___
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

[Markus Metz]

On Tue, Sep 27, 2016 at 5:55 PM, Vaclav Petras  wrote:
>
> 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).

+1

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

Le 28 septembre 2016 19:05:16 GMT+02:00, Martin Landa  
a écrit :
>Hi,
>
>2016-09-26 15:32 GMT+02:00 Moritz Lennert
>:
>> https://trac.osgeo.org/grass/ticket/3167
>
>since the blocker has been fixed I would vote for releasing 7.0.5 in
>the next days.

+1

Moritz


 Any objections? Martin

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

[Martin Landa]

Hi,

2016-09-26 15:32 GMT+02:00 Moritz Lennert :
> https://trac.osgeo.org/grass/ticket/3167

since the blocker has been fixed I would vote for releasing 7.0.5 in
the next days. Any objections? 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

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:  closed
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Database |Version:  unspecified
Resolution:  fixed|   Keywords:  postgresql db.connect
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by mlennert):

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


Comment:

 Replying to [comment:28 martinl]:
 >
 > {{{
 > v.in.ogr in=PG:dbname=grassremote layer=ruian.staty out=staty --o
 > }}}
 >
 > in GRASS 70 it fails with
 >
 > {{{
 > ERROR 1: PQconnectdb failed.
 > FATAL:  database "grassremote" does not exist
 >
 > ERROR: Unable to open data source 

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:27 martinl]:
 > Replying to [comment:26 mlennert]:
 > > Example (after disabling the condition check mentioned above):
 > >
 > > {{{
 > > createdb -h myRemoteServer testgrass2
 > > db.connect driver=pg database=testgrass2
 > > db.login host=myRemoteHost
 > > db.tables -p
 > > }}}
 > >
 > > Everything works, no tables shown. But then:
 >
 > OK, so it means that DB is empty, right?

 Yes, the database I want to use as attribute backend.

 >
 > > {{{
 > > D1/1: G_set_program_name(): v.in.ogr
 > > D1/1: Using dsn=PG:dbname=testgrass2 host=myRemoteServer
 > > ERREUR :Layer  not available
 > > D1/1: G_set_program_name(): g.gisenv
 > > }}}
 >
 > I do not understand - DB is empty, so why do you expect that `v.in.ogr`
 will not fail?

 Because my call to v.in.ogr was

 {{{
 v.in.ogr input="PG:dbname=testgrass" layer=boundary_county out=bc
 }}}

 i.e. trying to get a layer in db 'testgrass' and import it into my
 GISDBASE, storing the attributes into my database testgrass2. I.e. (as you
 note yourself in your next post here), v.in.ogr without a complete dsn
 string (i.e. containing host, etc) will try to connect to the current
 default attribute backend database, not the one you actually provide on
 the command line.

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

 I tested settings bellow:

 {{{
 db.connect -p
 driver: sqlite
 database: /opt/grassdata/pgtest/pg/sqlite/sqlite.db

 db.login -p
 pg|grassremote|||myserver|
 }}}

 The commands bellow works in GRASS 73/72/70:

 {{{
 db.tables dri=pg data=grassremote | grep staty
 ruian.staty
 }}}

 `v.in.ogr` works in GRASS 73/72:

 {{{
 v.in.ogr in=PG:dbname=grassremote layer=ruian.staty out=staty --o
 }}}

 in GRASS 70 it fails with

 {{{
 ERROR 1: PQconnectdb failed.
 FATAL:  database "grassremote" does not exist

 ERROR: Unable to open data source 

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 [comment:26 mlennert]:
 > Example (after disabling the condition check mentioned above):
 >
 > {{{
 > createdb -h myRemoteServer testgrass2
 > db.connect driver=pg database=testgrass2
 > db.login host=myRemoteHost
 > db.tables -p
 > }}}
 >
 > Everything works, no tables shown. But then:

 OK, so it means that DB is empty, right?

 > {{{
 > D1/1: G_set_program_name(): v.in.ogr
 > D1/1: Using dsn=PG:dbname=testgrass2 host=myRemoteServer
 > ERREUR :Layer  not available
 > D1/1: G_set_program_name(): g.gisenv
 > }}}

 I do not understand - DB is empty, so why do you expect that `v.in.ogr`
 will not fail?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] t.connect and t.rast.what not in GUI

[Blumentrath, Stefan]

Hi,

It seems that t.connect and t.rast.what have not been added to the GUI (both in 
G73 and G72)!

Please find attached a patch where I tried to add them. Hope that is the proper 
way.

I placed t.connect under temporal, but it might be better suited under 
Database, don't now...

Cheers
Stefan


add_t_modules_to_gui.diff
Description: add_t_modules_to_gui.diff
___
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:25 martinl]:
 > Replying to [comment:23 martinl]:
 >
 > > Thanks for testing, patch applied in all active branches
 (r69597-r69599)
 >
 > What is missing to downgrade priority at least and don't block 7.0.5
 release?

 There is a fundamental issue about importing data from remote server using
 v.in.ogr. See #comment:21 on part of the details. But looking into the
 code, I see even more weirdness: for some reason, v.in.ogr only looks at
 the default database of a pg db.connect-defined connection. I have no
 idea, why. v.in.ogr should import whatever data is available, even from
 other databases.

 Example (after disabling the condition check mentioned above):

 {{{
 createdb -h myRemoteServer testgrass2
 db.connect driver=pg database=testgrass2
 db.login host=myRemoteHost
 db.tables -p
 }}}

 Everything works, no tables shown. But then:


 {{{
 v.in.ogr input="PG:dbname=testgrass" layer=boundary_county out=bc
 }}}

 with testgrass defined in .grass7/dblogin as

 {{{
 pg|testgrass|||myRemoteServer|
 }}}

 I get (with DEBUG=1)


 {{{
 D1/1: G_set_program_name(): v.in.ogr
 D1/1: Using dsn=PG:dbname=testgrass2 host=myRemoteServer
 ERREUR :Layer  not available
 D1/1: G_set_program_name(): g.gisenv
 }}}

 i.e. it automatically tries to get the table from testgrass2, not
 testgrass.

 This comes from the fact that the name of the database is read as such:


 {{{
 dbname = db_get_default_database_name();
 }}}

 Instead of trying to read the database from the dsn string...

 In other words, it seems that importing data from a remote database in
 v.in.ogr needs to be done using a complete dsn string, even if db.login
 was called. And that this will only work on the command line, not in the
 import wizard. Do you confirm ?

 I guess we could call this a "known limitation" and just release as is, as
 it would need a substantial rewrite which I would like to avoid just
 before a release, but it is confusing to users. So maybe some hint about
 this in the import wizard ?

--
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 [comment:23 martinl]:

 > Thanks for testing, patch applied in all active branches (r69597-r69599)

 What is missing to downgrade priority at least and don't block 7.0.5
 release?

--
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 [comment:21 mlennert]:
 > If I skip the condition check (but obviously the 'PG:' check is needed),
 and I add something like this to main.c:

 Make sense to me to skip default driver check.

 > {{{
 > ===
 > --- main.c(révision 69596)
 > +++ main.c(copie de travail)
 > @@ -382,6 +382,10 @@
 >  strcat(dsn, " passwd=");
 >  strcat(dsn, conn.password);
 >  }
 > +if (conn.hostName) {
 > +strcat(dsn, " host=");
 > +strcat(dsn, conn.hostName);
 > +}
 >  /* TODO: host/port... */
 >  }
 >  else {
 > }}}

 Then I would add also a `port` item.

--
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 [comment:20 mlennert]:
 > FYI: I applied the patch to grass70_release and it seems to work
 perfectly there as well.

 Thanks for testing, patch applied in all active branches (r69597-r69599)

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

 In [changeset:"69599" 69599]:
 {{{
 #!CommitTicketReference repository="" revision="69599"
 db.connect: connection to remote database does not work (see #3167)
 (relbr72: merge r69597 from 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] #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):

 It might be something specific for Fedora. I hoped that diff could fix it,
 but I am clueless 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] #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:18 martinl]:
 > In [changeset:"69597" 69597]:
 > {{{
 > #!CommitTicketReference repository="" revision="69597"
 > db.connect: connection to remote database does not work (see #3167)
 > }}}

 FYI: I applied the patch to grass70_release and it seems to work perfectly
 there as well.

--
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:12 mlennert]:
 > Another issue linked to the wxGUI (reported by Stefan Lüdtke - I can
 confirm):
 >
 > "If everything is in db.login, I can connect to the db (as reported
 > earlier) and list tables. However I can neither link nor import them
 > because they are not listed in the gui box."
 >
 > I can see the database in the list, but once I select it, no tables are
 listed.
 >
 > Using
 >
 >
 > {{{
 > v.in.ogr input="PG:dbname=testgrass host=myRemoteServer"
 layer=boundary_county out=bc
 > }}}
 >
 > I can import a layer, but not using
 >
 >
 > {{{
 > v.in.ogr input="PG:dbname=testgrass" layer=boundary_county out=bc
 > }}}
 >
 > I imagine v.in.ogr does not take into account the .grass7/dblogin file.



 In grass70_release/vector/v.in.ogr/main.c, I see (line 359-60):

 {{{
 if (driver_name && strcmp(driver_name, "pg") == 0 &&
 G_strcasecmp(param.dsn->answer, "PG:") == 0) {
 }}}

 Two questions:

 * Why does the default driver have to be "pg", here ? We should import
 from postgres, whatever the default driver.
 * Unless I misunderstand how G_strcasecmp works,
 G_strcasecmp(param.dsn->answer, "PG:") will never be 0 (it would be only
 in the case that param.dsn->answer = 'PG:', but that should never be the
 case). So, IIUC, the condition is never met and whatever we would like to
 add to the dsn in terms of username, passwd, host, etc will never be
 added.

 If I skip the condition check (but obviously the 'PG:' check is needed),
 and I add something like this to main.c:


 {{{
 ===
 --- main.c  (révision 69596)
 +++ main.c  (copie de travail)
 @@ -382,6 +382,10 @@
  strcat(dsn, " passwd=");
  strcat(dsn, conn.password);
  }
 +if (conn.hostName) {
 +strcat(dsn, " host=");
 +strcat(dsn, conn.hostName);
 +}
  /* TODO: host/port... */
  }
  else {
 }}}


 v.in.ogr imports a layer from the database on a remote server if the login
 info is correct.

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

 In [changeset:"69598" 69598]:
 {{{
 #!CommitTicketReference repository="" revision="69598"
 db.connect: connection to remote database does not work (see #3167)
 (relbr72: merge r69597 from 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 martinl):

 In [changeset:"69597" 69597]:
 {{{
 #!CommitTicketReference repository="" revision="69597"
 db.connect: connection to remote database does not work (see #3167)
 }}}

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

 Thanks. Works for me now. And the date in the spatial database is
 overwritten.

 {{{
 > r.timestamp depth.02
 1 Jan 2015 00:01:00
 }}}

 This should be probably backported.

--
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:15 mlennert]:
 > Replying to [comment:14 martinl]:
 > > Replying to [comment:11 mlennert]:
 > > > 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.
 > >
 > > Please review attachment:dbmi_base_login2.diff
 >
 > Seems to work nicely, and much more elegant than my hack, thanks !

 P.S. Someone should probably check for mysql or other db backends, or ?

--
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 [comment:13 mlennert]:
 > One question about the new db.connect + db.login combination: if host
 information is stored in .grass7/dblogin file indexed by database, how
 does the system deal with two databases of the same name on two different
 hosts ?

 Currently it's not possible, items in the file are indexed by
 driver/database. Probably we could disable indexing at all. Please fill
 new ticket for 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] #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:14 martinl]:
 > Replying to [comment:11 mlennert]:
 > > 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.
 >
 > Please review attachment:dbmi_base_login2.diff

 Seems to work nicely, and much more elegant than my hack, thanks !

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

 * Attachment "dbmi_base_login2.diff" added.


--
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 [comment:11 mlennert]:
 > 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.

 Please review attachment:dbmi_base_login2.diff

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] missing / wrong link in raster3d.html

[Vaclav Petras]

On Wed, Sep 28, 2016 at 7:29 AM, Paulo van Breugel 
wrote:

> On https://grass.osgeo.org/grass70/manuals/raster3d.html the link to '3D
> raster introduction' (https://grass.osgeo.org/grass
> 70/manuals/3d%20rasterintro.html) does not exist. It probably should
> point to https://grass.osgeo.org/grass72/manuals/raster3dintro.html
>

I fixed that just yesterday for trunk (73):

https://grass.osgeo.org/grass73/manuals/raster3d.html
https://grass.osgeo.org/grass73/manuals/raster3dintro.html

I will be backported together with other changes but some review of the
current state would not hurt, especially for these two:

https://trac.osgeo.org/grass/changeset/69588
https://trac.osgeo.org/grass/changeset/69585
___
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):

 One question about the new db.connect + db.login combination: if host
 information is stored in .grass7/dblogin file indexed by database, how
 does the system deal with two databases of the same name on two different
 hosts ?

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

 Another issue linked to the wxGUI (reported by Stefan Lüdtke - I can
 confirm):

 "If everything is in db.login, I can connect to the db (as reported
 earlier) and list tables. However I can neither link nor import them
 because they are not listed in the gui box."

 I can see the database in the list, but once I select it, no tables are
 listed.

 Using


 {{{
 v.in.ogr input="PG:dbname=testgrass host=myRemoteServer"
 layer=boundary_county out=bc
 }}}

 I can import a layer, but not using


 {{{
 v.in.ogr input="PG:dbname=testgrass" layer=boundary_county out=bc
 }}}

 I imagine v.in.ogr does not take into account the .grass7/dblogin file.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] missing / wrong link in raster3d.html

[Paulo van Breugel]

On https://grass.osgeo.org/grass70/manuals/raster3d.html the link to '3D 
raster introduction' 
(https://grass.osgeo.org/grass70/manuals/3d%20rasterintro.html) does not 
exist. It probably should point to 
https://grass.osgeo.org/grass72/manuals/raster3dintro.html


Paulo

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

Re: [GRASS-dev] Show regression line in bivariate scatter plot?

[Paulo van Breugel]

On 28-09-16 10:52, Markus Neteler wrote:

Hi,

it would be great to show the regression line (result from "Plot
statistics") in the bivariate scatter plot.

Shall I open a ticket for this?

+1


thanks,
Markus
___
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] #1804: r.clump NULL handling

[GRASS GIS]

#1804: r.clump NULL handling
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Raster   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.clump
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by marisn):

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


Comment:

 Replying to [comment:7 neteler]:
 > Anything left here, marisn?
 There have been made serious improvements for the module thus it seems to
 be completely fixed for me.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Show regression line in bivariate scatter plot?

[Markus Neteler]

Hi,

it would be great to show the regression line (result from "Plot
statistics") in the bivariate scatter plot.

Shall I open a ticket for this?

thanks,
Markus
___
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):

 Unfortunatelly, no... still same behaviour with a freshly updated trunk
 r69591M :( 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] #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):

 I think there is definitely a place for parallel processing functions in
 grass.script and yours look really great !

 [alert: simplification] In my limited observations and own experience I
 have the feeling that grass.script caters well to the casual, generally
 functional, scientific programmer who just wants to glue together a
 specific workflow, whereas pygrass is much more pythonic and, therefore,
 caters more to those that have a pythonic, more object-oriented, way of
 thinking.[/alert: simplification]

 I guess the question is whether there might be enough common basis between
 the two implementations to not duplicate, but rather use one as the
 backend of the other, with the long-term idea of code maintainability ?

--
Ticket URL: 
GRASS GIS 

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