Re: [GRASS-user] Example project on GitLab

[Vaclav Petras]

On Wed, Nov 7, 2018 at 8:47 AM Bernardo Santos <
bernardo_brand...@yahoo.com.br> wrote:

>
> thanks for that, it'll be very useful. I think a similar approach can be
> used to build repositories for addons within GitHub, right?
>

Yes, when you involve Travis CI.


> Do you see clear advantages of using GitLab instead of GitHub for this
> purposes?
>

One other reason besides the private repos mentioned by KenM, the CI is
much better integrated then GitHub and Travis CI, so for example, you don't
have to pass any tokens to connect them bidirectionally in order to publish
web pages build by CI. The built web pages on GitLab don't need to be part
of the repository which may have some drawbacks but it is mostly an
advantage I would say. This is all kind of related to the GitLab approach
to the project - it is a primary a project and Git repo is just part of it
(GitHub interface is built around a repo).

Another thing is that you can download all the data and upload it to your
own GitLab instance if you don't want to use gitlab.com anymore (at least
that's what they claim). This relates to the fact that (most of) GitLab
itself is actually open source (!).

I'm not sure if it is an advantage for real work, but I personally enjoyed
working with the GitLab WebIDE and I created the whole example just using
that although at this point is misses spell check and you need to commit in
order to run the code.

One disadvantage of GitLab is that the CI is Linux only while GitHub has
macOS and recently they added Windows too.

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Finding why postgres database cannot be opened

[Rich Shepard]

On Wed, 7 Nov 2018, Rich Shepard wrote:


Almost all issues are now resolved,


  The issues with specifying database paths and needing a filled cat column
in the stations table have been resolved. v.db.connect shows a valid
connection to the database table:


v.db.connect map=stations -p

Vector map  is connected by:
layer <1/stations> table  in database
 through
driver  with key 

but, trying to display that map using v.colors in a script still fails to
find the database:


$HOME/documents/white-papers/geochemistry/willamette-river-mercury/scripts/grass-display-sample-sites.sh

d.vect complete.
d.vect complete.
DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not exist
WARNING: Unable to open database
 
 by driver 
ERROR: Unable to open database
   
   by driver 

  The script:
#!/usr/bin/bash

db.connect driver=pg database=willamette-river-hg
g.region vect=wrb
d.mon start=wx0
d.vect map=wrb col=black fill_col=none
d.vect map=wrb_rivers col=blue fill_col=blue
v.colors map=stations use=attr column=howmany rules=rules.txt rgb_col=bin_col 
--o

and the color rules file:

1 231:00:00
10 231:00:00
11 89:00:00
20 89:00:00
21 231:00:231
30 231:00:231
31 231:173:00
40 231:173:00
41 231:115:00
50 231:115:00
51 00:231:57
60 00:231:57
61 115:231:00
70 115:231:00

TIA,

Rich

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

Re: [GRASS-user] Finding why postgres database cannot be opened

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


I am afraid that manually adding a cat column and populating it with
sequential numbers will not work: how do you assure that the cat numbers
and corresponding attribute values indeed correspond to the cat values of
the vector features? Chances are high that vector features get linked to
wrong attributes.


Markus M,

  Grass told me the stations table has no categories, which it does not
because the map's attribute table was derived from the pre-existing postgres
database table and the geometry created by the easting/northing pairs in
that table.

  The other maps and tables were created from agency-sourced GIS
repositories and grass created cat columns for them, so it's only the
stations table needing that column to be added.


db.select sql="select * from stations limit 3"

site_nbr|site_name|lon|lat|easting|northing|start_date|end_date|howmany|bin_col|cat
10332|Willamette R. at SP RR Bridge 
(Portland)|-122.7475|45.577944|||1979-11-06|2003-06-19|25|231:00:231|
10917|Pudding R. at Hwy 99E 
(Aurora)|-122.748972|45.233806|||1979-11-06|2008-03-26|22|231:00:231|
10376|McKenzie R. at Coburg 
Road|-123.046194|44.112722|||1980-05-07|2011-01-04|40|231:173:00|

  No cat values there now. But, updating the table and setting a distinct cat
number for each site_nbr will fill that column.

Thanks,

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

Re: [GRASS-user] Finding why postgres database cannot be opened

[Markus Metz]

On Wed, Nov 7, 2018 at 8:40 PM Rich Shepard 
wrote:
>
> On Wed, 7 Nov 2018, Moritz Lennert wrote:
>
> > I think you need to slow down a bit and try to review your basic
> > understanding of things (maybe [1] could do with a bit more substance).
>
> Moritz,
>
>I do need to step back a bit.
>
> > You are trying to connect to a database that is called
> > "/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg",
not (as
> > it should be) "willamette-river-hg".
>
>Yes, I see where I kept confusing path names for the sqlite and
postgres
> tables.
>
>Almost all issues are now resolved, but I need to add a 'cat' column to
> the postgres stations table (it has more columns than does the sqlite
one),
> so I'll so this with psql and insert sequential numbers in that column
that
> follow the site_nbr columns. Looking at all tables, I think this is the
last
> hurdle to displaying the stations table.

I am afraid that manually adding a cat column and populating it with
sequential numbers will  not work: how do you assure that the cat numbers
and corresponding attribute values indeed correspond to the cat values of
the vector features? Chances are high that vector features get linked to
wrong attributes.

Considering all the modifications that you have done in the meantime I
suggest to start from scratch:

1. decide on the default database connection you want to use
2. set up the default database connection if not sqlite
3. test the database connection e.g. with db.tables
4. create vector maps

Markus M
>
>Thanks very much.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.tile behaviour

[Sajid Pareeth]

Thank you both,

I got confused between first and last row tiles and the middle ones.
The overlap is fine on first and last row tiles.

Regards

Sajid

On Wed, Nov 7, 2018 at 7:37 PM Markus Metz 
wrote:

>
>
> On Wed, Nov 7, 2018 at 7:06 PM Veronica Andreo 
> wrote:
> >
> > Hi Sajid,
> >
> > I have never used r.tile before, but checking the code [1], it
> multiplies the overlap by 2, so there's why. Now guesstimating, if I set an
> overlap of 50, I would expect to have that overlap on both sides of the
> desired size of the tiles, so maybe that's why it is doubled ?
>
> In princliple that's correct, but not for the first and last row and
> column of tiles.
>
> In Sajid's example, the first and last row of tiles should have 725 rows
> (675 + 50) and all other tiles 775 rows (675 + 2 * 50). Accordingly for
> columns.
>
> That should be relatively easy to fix.
>
> Markus M
> >
> > HTH,
> > Vero
> >
> > [1]
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.tile/main.c#L101
> >
> > El mié., 7 nov. 2018 a las 15:08, Sajid Pareeth ()
> escribió:
> >>
> >> Hi all
> >>
> >> The r.tile module don't have overwrite flag, so if we re run the module
> with different parameters but with same output prefix name, then it will
> rewrite output with out warning.
> >> Is this intentional?
> >>
> >> Another point is, if I use overlap option it adds double the overlap
> cells to the output maps.
> >>
> >> For example in the NC location:
> >>>
> >>> r.info elevation -g
> >>
> >> rows=1350
> >> cols=1500
> >>
> >>> r.tile input=elevation output=elev_tile width=750 height=675
> >>> r.info elev_tile-001-001 -g
> >>
> >> rows=675
> >> cols=750
> >>
> >>> r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
> >>> r.info elev_tile-001-001 -g
> >>
> >> rows=775 (+ 100)
> >> cols=850 (+ 100)
> >>
> >> In the last case the rows and cols should be 725 and 800 respectively,
> as it should add 50 cells as overlap to each tile? Or am I missing
> something?
> >>
> >> Regards
> >>
> >> Sajid
> >>
> >>
> >>
> >>
> >> ___
> >> grass-user mailing list
> >> grass-user@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/grass-user
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Finding why postgres database cannot be opened

[Rich Shepard]

On Wed, 7 Nov 2018, Moritz Lennert wrote:

I think you need to slow down a bit and try to review your basic 
understanding of things (maybe [1] could do with a bit more substance).


Moritz,

  I do need to step back a bit.

You are trying to connect to a database that is called 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg", not (as 
it should be) "willamette-river-hg".


  Yes, I see where I kept confusing path names for the sqlite and postgres
tables.

  Almost all issues are now resolved, but I need to add a 'cat' column to
the postgres stations table (it has more columns than does the sqlite one),
so I'll so this with psql and insert sequential numbers in that column that
follow the site_nbr columns. Looking at all tables, I think this is the last
hurdle to displaying the stations table.

  Thanks very much.

Regards,

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

Re: [GRASS-user] Finding why postgres database cannot be opened

[Moritz Lennert]

Hi Rich,

On 7/11/18 19:55, Rich Shepard wrote:
   Grass seems to recognize the postgres data base and that I'm logged 
in to

it:


db.connect -p

driver: pg
database: 
/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg



db.login driver=pg database=willamette-river-hg --o

WARNING: DB connection  already exists and will be
  overwritten

   If the mapset recognizes that geometry attributes are stored in the
postgres database, and user me has access to these attribute tables, what
might be the cause of this error (seen with multiple maps):


db.columns table=fishes

DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does 
not exist


WARNING: Unable to open database
  


  by driver 
DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does 
not exist




I think you need to slow down a bit and try to review your basic 
understanding of things (maybe [1] could do with a bit more substance).


You are trying to connect to a database that is called 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg", 
not (as it should be) "willamette-river-hg".


Also, as MarkusM has already mentioned:

- db.connect does not test for the existence of the database. It just 
sets the content of the file definining the default mapset connection 
and outputs the content of this file. Use db.test to test your connection.


- The same goes for db.login: it just writes out the login info into a 
file. AFAIR, it is not absolutely necessary to use db.login to be able 
to connect to a database, especially if you do not need a password for 
connection.


- If you want to check the database connection of a specific vector map, 
please use v.db.connect -p.


Moritz



[1] https://grass.osgeo.org/grass74/manuals/databaseintro.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Finding why postgres database cannot be opened

[Rich Shepard]

  Grass seems to recognize the postgres data base and that I'm logged in to
it:


db.connect -p

driver: pg
database: /home/rshepard/data/grassdata/willamette_basin/willamette-river-hg


db.login driver=pg database=willamette-river-hg --o

WARNING: DB connection  already exists and will be
 overwritten

  If the mapset recognizes that geometry attributes are stored in the
postgres database, and user me has access to these attribute tables, what
might be the cause of this error (seen with multiple maps):


db.columns table=fishes

DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not exist

WARNING: Unable to open database
 
 by driver 
DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not exist

TIA,

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

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


for pg you don't specify a path/to/file as database, instead you use a
name: database=willamette-river-hg


Markus M,

  Well, darn! I did not pick up on this difference when reading the manual
pages. It certainly makes a difference!

  When I get the maps connected to the postgres tables can I then remove the
sqlite versions? The v.db.droptable looks like it would act on the postgres
table rather than the sqlite table.

Many thanks,

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

Re: [GRASS-user] r.tile behaviour

[Markus Metz]

On Wed, Nov 7, 2018 at 7:06 PM Veronica Andreo  wrote:
>
> Hi Sajid,
>
> I have never used r.tile before, but checking the code [1], it multiplies
the overlap by 2, so there's why. Now guesstimating, if I set an overlap of
50, I would expect to have that overlap on both sides of the desired size
of the tiles, so maybe that's why it is doubled ?

In princliple that's correct, but not for the first and last row and column
of tiles.

In Sajid's example, the first and last row of tiles should have 725 rows
(675 + 50) and all other tiles 775 rows (675 + 2 * 50). Accordingly for
columns.

That should be relatively easy to fix.

Markus M
>
> HTH,
> Vero
>
> [1]
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.tile/main.c#L101
>
> El mié., 7 nov. 2018 a las 15:08, Sajid Pareeth ()
escribió:
>>
>> Hi all
>>
>> The r.tile module don't have overwrite flag, so if we re run the module
with different parameters but with same output prefix name, then it will
rewrite output with out warning.
>> Is this intentional?
>>
>> Another point is, if I use overlap option it adds double the overlap
cells to the output maps.
>>
>> For example in the NC location:
>>>
>>> r.info elevation -g
>>
>> rows=1350
>> cols=1500
>>
>>> r.tile input=elevation output=elev_tile width=750 height=675
>>> r.info elev_tile-001-001 -g
>>
>> rows=675
>> cols=750
>>
>>> r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
>>> r.info elev_tile-001-001 -g
>>
>> rows=775 (+ 100)
>> cols=850 (+ 100)
>>
>> In the last case the rows and cols should be 725 and 800 respectively,
as it should add 50 cells as overlap to each tile? Or am I missing
something?
>>
>> Regards
>>
>> Sajid
>>
>>
>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Rich Shepard wrote:


Other maps still have their tables in the sqlite.db; e.g.,
1/FishD_AllSpecies_January2012|all_species|cat|$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db|sqlite


  Perhaps this is the problem: some maps seem to have a source name as well
as a table name. How can I remove this; for example, removing the string
"FishD_AllSpecies_January2012|' from grass?

  Can I simply edit that file?

Regards,

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

Re: [GRASS-user] v.colors usage

[Markus Metz]

On Wed, Nov 7, 2018 at 7:06 PM Rich Shepard 
wrote:
>
> On Wed, 7 Nov 2018, Markus Metz wrote:
>
> > for sqlite, the database must be a path to a sqlite database, in your
> > case, as you used yourself before:
> >
database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"
>
>Well, the situation here has become FUBAR and I need help fixing
things.
>
>The geometry/database in grass has 8 maps, each with an associated
> attribute table. The stations map is connected to the postgres table:
>
> $ less data/grassdata/willamette_basin/mercury/vector/stations/dbln
>
1/stations|stations|cat|/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg|pg
>
> Other maps still have their tables in the sqlite.db; e.g.,
>
1/FishD_AllSpecies_January2012|all_species|cat|$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db|sqlite
>
> so I tried to re-connect it to the postgres table using v.db.connect with
> this result:
>
> > v.db.connect map=all_species driver=pg
database="$HOME/data/grassdata/willamette_basin/willamette-river-hg"
table=all_species -o
> DBMI-PostgreSQL driver error:
> Connection failed.

for pg you don't specify a path/to/file as database, instead you use a
name: database=willamette-river-hg

Markus M

> FATAL:  database
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not
exist
> DBMI-PostgreSQL driver error:
> Connection failed.
> FATAL:  database
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not
exist
> WARNING: Unable to open database
>

>   by driver 
> WARNING: Unable open database
>

>   by driver 
> ERROR: Table  does not exist in database
>

>
>Grass is connected to that database and I'm logged in:
> > db.connect -p
> driver: pg
> database:
/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg
>
> and, of course, the table 'all_species' exists there:
>
> willamette-river-hg=# \d
>   List of relations
>   Schema |  Name  | Type  |  Owner
> ++---+--
>   public | all_species| table | rshepard
>
>So, I've obviously missed a step or the proper syntax and have become
> sufficiently confused by what's to be done when connected to each database
> that I need to be shown the True Path to transferring the rest of the map
> attribute tables to the ones db.cop(ied) to the postgres database.
>
> TIA,
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.tile behaviour

[Veronica Andreo]

Hi Sajid,

I have never used r.tile before, but checking the code [1], it multiplies
the overlap by 2, so there's why. Now guesstimating, if I set an overlap of
50, I would expect to have that overlap on both sides of the desired size
of the tiles, so maybe that's why it is doubled ?

HTH,
Vero

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.tile/main.c#L101

El mié., 7 nov. 2018 a las 15:08, Sajid Pareeth ()
escribió:

> Hi all
>
> The r.tile module don't have overwrite flag, so if we re run the module
> with different parameters but with same output prefix name, then it will
> rewrite output with out warning.
> Is this intentional?
>
> Another point is, if I use overlap option it adds double the overlap cells
> to the output maps.
>
> For example in the NC location:
>
>> r.info elevation -g
>>
> rows=1350
> cols=1500
>
> r.tile input=elevation output=elev_tile width=750 height=675
>> r.info elev_tile-001-001 -g
>>
> rows=675
> cols=750
>
> r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
>> r.info elev_tile-001-001 -g
>
> rows=775 (+ 100)
> cols=850 (+ 100)
>
> In the last case the rows and cols should be 725 and 800 respectively, as
> it should add 50 cells as overlap to each tile? Or am I missing something?
>
> Regards
>
> Sajid
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


for sqlite, the database must be a path to a sqlite database, in your
case, as you used yourself before:
database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"


  Well, the situation here has become FUBAR and I need help fixing things.

  The geometry/database in grass has 8 maps, each with an associated
attribute table. The stations map is connected to the postgres table:

$ less data/grassdata/willamette_basin/mercury/vector/stations/dbln
1/stations|stations|cat|/home/rshepard/data/grassdata/willamette_basin/willamette-river-hg|pg

Other maps still have their tables in the sqlite.db; e.g.,
1/FishD_AllSpecies_January2012|all_species|cat|$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db|sqlite

so I tried to re-connect it to the postgres table using v.db.connect with
this result:


v.db.connect map=all_species driver=pg 
database="$HOME/data/grassdata/willamette_basin/willamette-river-hg" 
table=all_species -o

DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not exist
DBMI-PostgreSQL driver error:
Connection failed.
FATAL:  database 
"/home/rshepard/data/grassdata/willamette_basin/willamette-river" does not exist
WARNING: Unable to open database
 
 by driver 
WARNING: Unable open database
 
 by driver 
ERROR: Table  does not exist in database
   

  Grass is connected to that database and I'm logged in:

db.connect -p

driver: pg
database: /home/rshepard/data/grassdata/willamette_basin/willamette-river-hg

and, of course, the table 'all_species' exists there:

willamette-river-hg=# \d
 List of relations
 Schema |  Name  | Type  |  Owner 
++---+--

 public | all_species| table | rshepard

  So, I've obviously missed a step or the proper syntax and have become
sufficiently confused by what's to be done when connected to each database
that I need to be shown the True Path to transferring the rest of the map
attribute tables to the ones db.cop(ied) to the postgres database.

TIA,

Rich


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

[GRASS-user] ps.map read

[Frank David]

Hello all,

If I use  instruction inside my psmap file the command > ps.map 
input=myfile.psmap output=myfile.ps does not work and the exit message is :


enter 'help' for help, 'end' when done, 'exit' to quit

But if I execute inside a shell loop, like > ls 01*.psmap |while read 
fic;do ps.map input="${fic}" output="${fic%.*}.ps" --overwrite;done it 
works! But I cannot run multiple ps.map with ls *.psmap. The error 
message is :


ERREUR :myfile.psmap : illegal request

If I comment  instruction with # inside my psmap. everything is 
working.


I have put my  just before the last  instruction. The read 
file contains only a v.points layer.


Using a  is very powerfull, but ps.map in a shell loop is also 
very usefull... to be able to do both would be ideal !


Thanks for your tricks if any

Cheers,

Frank

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

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


for sqlite, the database must be a path to a sqlite database, in your case,
as you used yourself before:
database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"


Markus M,

  Thanks again for your advice here and using only db.connect -p for the
sqlite database. Won't be long before I've gained enough experience to get
commands right the first time.

Best regards,

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

Re: [GRASS-user] Example project on GitLab

[Ken Mankoff]

Gitlab supports private repositories. Useful for early development for some
people

Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.

On Wed, Nov 7, 2018, 05:47 Bernardo Santos  Hi Vaclav,
>
> thanks for that, it'll be very useful. I think a similar approach can be
> used to build repositories for addons within GitHub, right?
> Do you see clear advantages of using GitLab instead of GitHub for this
> purposes?
>
> Best,
> Bernardo Niebuhr
>
> Em segunda-feira, 5 de novembro de 2018 17:50:38 BRST, Vaclav Petras <
> wenzesl...@gmail.com> escreveu:
>
>
>
>
> On Mon, Nov 5, 2018 at 2:43 PM Ken Mankoff  wrote:
>
> I think I will find it useful in helping some of my custom scripts to
> official plugins.
>
>
> Glad to hear that! Thanks for sharing your code!
>
>
>
>
> On Fri, Nov 2, 2018 at 7:08 PM Vaclav Petras  wrote:
>
> Dear users and devs,
>
> I've created an example project at GitLab. It is a GRASS GIS module
> written in Python. It uses GitLab CI to build the module and publish its
> documentation as a website.
>
> https://gitlab.com/vpetras/r.example.plus
>
> If you are familiar with GitHub, GitLab will feel familiar as well (we can
> discuss the differences later), but the following terminology comparison
> may come useful:
>
>
> https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/
>
> Otherwise, I hope the project should describe itself and if something is
> missing or is not documented enough, your can submit an issue or a merge
> request.
>
> Best,
> Vaclav
>
> PS: We can create a GitLab group for GRASS GIS and move this project there.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Markus Metz]

On Wed, Nov 7, 2018 at 5:03 PM Markus Metz 
wrote:
>
>
>
> On Wed, Nov 7, 2018 at 4:51 PM Rich Shepard 
wrote:
> >
> > On Wed, 7 Nov 2018, Markus Metz wrote:
> >
> > > v.db.connect sets the table and database connection for a given,
existing
> > > vector. The default database connection can be overridden with the
driver=
> > > and database= options
> >
> >I reset the attribute database to the sqlite default with 'db.connect
> > driver=sqlite database=mercury' and that's the database shown in
> > response to db.connect -p:
>
> for sqlite, the database must be a path to a sqlite database, in your
case, as you used yourself before:
>
> database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"

for default sqlite databases you can use simply

db.connect -d
>
> Markus M
> >
> > > db.connect -p
> > driver: sqlite
> > database: mercury
> >
> >The next step in the example is to list the tables:
> > > db.tables -p
> > DBMI-SQLite driver error:
> > Unable to open database: mercury
> > unable to open database file
> >
> > DBMI-SQLite driver error:
> > Unable to open database: mercury
> > unable to open database file
> >
> > ERROR: Unable to open database 
> >
> >What error have I made here?
> >
> > Rich
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Markus Metz]

On Wed, Nov 7, 2018 at 4:51 PM Rich Shepard 
wrote:
>
> On Wed, 7 Nov 2018, Markus Metz wrote:
>
> > v.db.connect sets the table and database connection for a given,
existing
> > vector. The default database connection can be overridden with the
driver=
> > and database= options
>
>I reset the attribute database to the sqlite default with 'db.connect
> driver=sqlite database=mercury' and that's the database shown in
> response to db.connect -p:

for sqlite, the database must be a path to a sqlite database, in your case,
as you used yourself before:

database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"

Markus M
>
> > db.connect -p
> driver: sqlite
> database: mercury
>
>The next step in the example is to list the tables:
> > db.tables -p
> DBMI-SQLite driver error:
> Unable to open database: mercury
> unable to open database file
>
> DBMI-SQLite driver error:
> Unable to open database: mercury
> unable to open database file
>
> ERROR: Unable to open database 
>
>What error have I made here?
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


v.db.connect sets the table and database connection for a given, existing
vector. The default database connection can be overridden with the driver=
and database= options


  I reset the attribute database to the sqlite default with 'db.connect
driver=sqlite database=mercury' and that's the database shown in
response to db.connect -p:


db.connect -p

driver: sqlite
database: mercury

  The next step in the example is to list the tables:

db.tables -p

DBMI-SQLite driver error:
Unable to open database: mercury
unable to open database file

DBMI-SQLite driver error:
Unable to open database: mercury
unable to open database file

ERROR: Unable to open database 

  What error have I made here?

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

Re: [GRASS-user] Example project on GitLab

[Ken Mankoff]

Gitlab supports private repositories. Useful for early development for some
people.

Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.

On Wed, Nov 7, 2018, 05:47 Bernardo Santos  Hi Vaclav,
>
> thanks for that, it'll be very useful. I think a similar approach can be
> used to build repositories for addons within GitHub, right?
> Do you see clear advantages of using GitLab instead of GitHub for this
> purposes?
>
> Best,
> Bernardo Niebuhr
>
> Em segunda-feira, 5 de novembro de 2018 17:50:38 BRST, Vaclav Petras <
> wenzesl...@gmail.com> escreveu:
>
>
>
>
> On Mon, Nov 5, 2018 at 2:43 PM Ken Mankoff  wrote:
>
> I think I will find it useful in helping some of my custom scripts to
> official plugins.
>
>
> Glad to hear that! Thanks for sharing your code!
>
>
>
>
> On Fri, Nov 2, 2018 at 7:08 PM Vaclav Petras  wrote:
>
> Dear users and devs,
>
> I've created an example project at GitLab. It is a GRASS GIS module
> written in Python. It uses GitLab CI to build the module and publish its
> documentation as a website.
>
> https://gitlab.com/vpetras/r.example.plus
>
> If you are familiar with GitHub, GitLab will feel familiar as well (we can
> discuss the differences later), but the following terminology comparison
> may come useful:
>
>
> https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/
>
> Otherwise, I hope the project should describe itself and if something is
> missing or is not documented enough, your can submit an issue or a merge
> request.
>
> Best,
> Vaclav
>
> PS: We can create a GitLab group for GRASS GIS and move this project there.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


a short summary (others may have similar problems).

db.connect sets the default database connection for subsequently created
vector maps, already existing vector maps are not affected

v.db.connect sets the table and database connection for a given, existing
vector. The default database connection can be overridden with the driver=
and database= options

Hope that makes it clearer


Markus M,

  Yes, it certainly does make it clearer. Thanks for your patient help.

Best regards,

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

[GRASS-user] r.tile behaviour

[Sajid Pareeth]

Hi all

The r.tile module don't have overwrite flag, so if we re run the module
with different parameters but with same output prefix name, then it will
rewrite output with out warning.
Is this intentional?

Another point is, if I use overlap option it adds double the overlap cells
to the output maps.

For example in the NC location:

> r.info elevation -g
>
rows=1350
cols=1500

r.tile input=elevation output=elev_tile width=750 height=675
> r.info elev_tile-001-001 -g
>
rows=675
cols=750

r.tile input=elevation output=elev_tile width=750 height=675 overlap=50
> r.info elev_tile-001-001 -g

rows=775 (+ 100)
cols=850 (+ 100)

In the last case the rows and cols should be 725 and 800 respectively, as
it should add 50 cells as overlap to each tile? Or am I missing something?

Regards

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

Re: [GRASS-user] v.colors usage

[Markus Metz]

On Wed, Nov 7, 2018 at 2:39 PM Rich Shepard 
wrote:
>
> On Wed, 7 Nov 2018, Markus Metz wrote:
>
> > I suggested v.db.droptable, not db.droptable. db.* commands work on
> > databases whereas v.* commands work on vectors. Thus you need to use
> > v.db.connect, not db.connect, to connect a table to a vector, e.g.:
> >
> > v.db.connect map=stations driver=pg database="willamette-river-hg"
> > table=stations layer=1
>
> Markus M,
>
>Okay. Another step in my learning to use postgres databases with grass
> rther than the default.
>
>I don't know if this makes a difference, but the stations table has the
> same name in both databases. The grass map attribute table came from the
> postgres table. The other maps were developed in grass and I used db.copy
> with a name change to insert them in the postgres database.
>
>I'll use v.db.connect and v.db.droptable now.

a short summary (others may have similar problems).

db.connect sets the default database connection for subsequently created
vector maps, already existing vector maps are not affected

v.db.connect sets the table and database connection for a given, existing
vector. The default database connection can be overridden with the driver=
and database= options

Hope that makes it clearer

Markus M
>
> Many thanks,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Example project on GitLab

[Bernardo Santos]

 Hi Vaclav,
thanks for that, it'll be very useful. I think a similar approach can be used 
to build repositories for addons within GitHub, right?Do you see clear 
advantages of using GitLab instead of GitHub for this purposes?
Best,Bernardo Niebuhr

Em segunda-feira, 5 de novembro de 2018 17:50:38 BRST, Vaclav Petras 
 escreveu:  
 
 

On Mon, Nov 5, 2018 at 2:43 PM Ken Mankoff  wrote:

I think I will find it useful in helping some of my custom scripts to official 
plugins.


Glad to hear that! Thanks for sharing your code!

 
On Fri, Nov 2, 2018 at 7:08 PM Vaclav Petras  wrote:

Dear users and devs,
I've created an example project at GitLab. It is a GRASS GIS module written in 
Python. It uses GitLab CI to build the module and publish its documentation as 
a website.

https://gitlab.com/vpetras/r.example.plus
If you are familiar with GitHub, GitLab will feel familiar as well (we can 
discuss the differences later), but the following terminology comparison may 
come useful:

https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/
Otherwise, I hope the project should describe itself and if something is 
missing or is not documented enough, your can submit an issue or a merge 
request.
Best,Vaclav
PS: We can create a GitLab group for GRASS GIS and move this project there.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] v.colors usage

[Rich Shepard]

On Wed, 7 Nov 2018, Markus Metz wrote:


I suggested v.db.droptable, not db.droptable. db.* commands work on
databases whereas v.* commands work on vectors. Thus you need to use
v.db.connect, not db.connect, to connect a table to a vector, e.g.:

v.db.connect map=stations driver=pg database="willamette-river-hg"
table=stations layer=1


Markus M,

  Okay. Another step in my learning to use postgres databases with grass
rther than the default.

  I don't know if this makes a difference, but the stations table has the
same name in both databases. The grass map attribute table came from the
postgres table. The other maps were developed in grass and I used db.copy
with a name change to insert them in the postgres database.

  I'll use v.db.connect and v.db.droptable now.

Many thanks,

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

Re: [GRASS-user] partial vector copy to smaller territory

[Markus Metz]

On Wed, Nov 7, 2018 at 11:18 AM Frank David  wrote:
>
> Le 06/11/2018 à 21:36, Markus Metz a écrit :
>
>
>
> On Tue, Nov 6, 2018 at 4:03 PM Frank David  wrote:
> >
> >
> > Le 05/11/2018 à 14:23, Frank David a écrit :
> > >
> > > Le 02/11/2018 à 22:27, Markus Metz a écrit :
> > >>
> > >>
> > >> On Fri, Nov 2, 2018 at 6:32 PM Frank David  > >> > wrote:
> > >> >
> > >> > Le 02/11/2018 à 14:43, Markus Metz a écrit :
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Nov 2, 2018 at 11:58 AM Frank David  > >> > wrote:
> > >> > >
> > >> > > Le 31/10/2018 à 20:57, Markus Metz a écrit :
> > >> > >
> > >> > > Hi Frank,
> > >> > >
> > >> > > On Wed, Oct 31, 2018 at 1:39 PM Frank David
> > >> mailto:frank.da...@geophom.fr>> wrote:
> > >> > > >
> > >> > > > Hello Vero,
> > >> > > >
> > >> > > > Thanks for your reply. It took almost one hour to extract my
> > >> area (I guess because of topology). I do the same with Qgis from a
> > >> shape in less than 10 minutes (but with several operations)... it's
> > >> may be a bad idea to have a so heavy vector map in Grass...
> > >> > >
> > >> > > this kind of operation could be much faster in latest GRASS 7.4
> > >> than in any previous versions. Which GRASS version are you using?
> > >> > >
> > >> > > Hello Markus,
> > >> > >
> > >> > > I'm using 7.4.1 on debian9
> > >> > >
> > >> > > But my grass db folder  is on a small server (Synology NAS), so
> > >> may be the network makes slow down the operation ?
> > >> >
> > >> > This is possible, but it should not slow it down that much: 10 min
> > >> vs 1 hour
> > >> >
> > >> > Can you provide a link to the vector from which you want to extract
> > >> a small area, and the command you used to extract a small area? Maybe
> > >> there is scope for optimization.
> > >> >
> > >> > Markus,
> > >> >
> > >> > The data is CorineLandCover for france. You can download 400mo here
> > >> > https://we.tl/t-tvldlmkVw3
> > >> >
> > >> > First I have imported the shape in PERMANENT
> > >> >
> > >> > and I do : v.extract --verbose input=CLC12_FR_RGF@PERMANENT
> > >> where=CODE_12 IN (111,112,131,311,312,313,324) output=clc12
> > >> >
> > >> > Hope it helps you...
> > >>
> > >> import of the shapefile with v.in.ogr takes here 5 minutes
> > >> v.extract takes here 27 seconds instead of 1 hour
> > >>
> > >> "here" means a laptop with Intel Core i7 4th generation and standard
> > >> SATA SSD, i.e. no fancy new high-speed system at all.
> > >>
> > >> I am afraid this does not help you. What could take long is writing
> > >> attributes, depending on the database connection. I am using the
> > >> default sqlite database.
> > >>
> > >> You could use top to check if v.extract is running at 100%.
> > >
> > > Hello Markus,
> > >
> > > Thank you for your help.
> > >
> > > I'm trying to do again the operation on local machine. I want fisrt,
> > > create a vector with only selected data (on full France area). But
> > > I've met a problem with v.extract.
> > >
> > > v.extract --overwrite --verbose input=CLC12_FR_RGF@PERMANENT type=area
> > > where=CODE_12 IN (111,112,121,311,312,313,324)
> > > output=CLC12_FR_RGF_BOISBATI@PERMANENT
> > > Loading categories from table ...
> > > DBMI-DBF erreur de pilote :
> > > SQL parser error (syntax error, unexpected NAME processing
> > > 'IN') in statement:
> > > SELECT cat FROM CLC12_FR_RGF WHERE CODE_12 IN
> > > (111,112,121,311,312,313,324)
> > > Unable to open cursor.
> > > DBMI-DBF erreur de pilote :
> > > SQL parser error (syntax error, unexpected NAME processing
> > > 'IN') in statement:
> > > SELECT cat FROM CLC12_FR_RGF WHERE CODE_12 IN
> > > (111,112,121,311,312,313,324)
> > > Unable to open cursor.
> > > ERROR: Unable select records from table 
> > >
> > > It looks that grass does not recognized "IN" sql condition. If I force
> > > layer=-1, it runs bur the output vector is the same as input one.
> > >
> > > Am I wrong somewhere ? I use Grass 7.4.2 on debian9.
> > >
> > > Thank you for your help.
> > >
> > > Frank
> > >
> > Hi,
> >
> > I've repeated the operation v.in.ogr and v.extract with success on
> > different grass mapset, but I get always the same error (on v.extract :
> > see above) only with one of my local grass mapset (PERMANENT). I do not
> > understand what happens...
>
> In the current mapset, the default database connection must not be DBF.
You can reset the default database connection to sqlite with
>
> db.connect -d
> After that verify with
> db.connect -p
> that sqlite is indeed the default database connection.
>
> Now you can repeat with v.in.ogr + v.extract
>
> Markus M
>
> I'm afraid it's not the problem...
>
> db.connect -d

> Pilote par défaut / base de données définie à :
> pilote : sqlite
> base : /media/hdd1/grassdata/France_L93/PERMANENT/sqlite/sqlite.db
> (Wed Nov  7 10:46:01 2018) La commande s'est terminée (0 sec)

> (Wed Nov  7 10:46:29 2018)

> db.connect -p

> driver: sqlite
> database: