Re: [GRASS-user] v.colors usage

[Markus Metz]

On Tue, Nov 6, 2018 at 11:57 PM Rich Shepard 
wrote:
>
> On Tue, 6 Nov 2018, Markus Metz wrote:
>
> > Apparently the table (not the vector map) stations exists twice: once in
> > the sqlite database, once in the pg willamette-river-hg database. This
is
> > the reason for the confusion. A vector map can have a table that is not
in
> > the default database as reported by db.connect -p.
>
> Markus M,
>
>I did not realize this. I thought that using db.connect with the pg
driver
> would use that table exclusively. This is good to know.
>
> > db.connect as well as other db.* commands use the default database
> > connection reported by db.connect -p unless specified, e.g.
>
>Well, it didn't here when I tried using the v.colors command. :-(
>
> > You have to change the database connection for a given vector map with
> > v.db.connect. To be safe (avoiding confusion) you might use
v.db.droptable
> > first. Make sure you transfer attribute values first, e.g. with db.copy.
>
>I had used db.copy to copy all the stations map tables to postgres
except
> for the stations table because that existed first in the postgres
database,
> and attributes there were expoorted and used with v.in.ascii to create the
> grass map.
>
>Changing the database connection to the sqlite default I thought the
> stations table was deleted:
>
> > db.droptable -f driver=sqlite table=stations

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

HTH,

Markus M

> Forcing ...
> WARNING: Deleting table  which is attached to following map(s):
> WARNING: stations@mercury
>
> but,
>
> > db.connect driver=pg database="willamette-river-hg"
> GRASS 7.7.svn (willamette_basin):~/data/grassdata/willamette_basin >
db.connect -p
> driver: pg
> database: willamette-river-hg
>
> > v.colors -c map=stations use=attr column=howmany rules=rules.txt
rgb_col=bin_col --o
> DBMI-SQLite driver error:
> Error in sqlite3_prepare(): select * from stations where oid < 0
> no such table: stations
>
> DBMI-SQLite driver error:
> Error in sqlite3_prepare(): select * from stations where oid < 0
> no such table: stations
>
> ERROR: Column  not found in table 
>
> > db.connect -p driver: pg database: willamette-river-hg schema: group:
> GRASS 7.7.svn (willamette_basin):~/data/grassdata/willamette_basin
>
> > v.db.connect map=stations -p Vector map  is connected by:
layer
> <1/stations> table  in database
> 
> through driver  with key 
>
>So, grass tells me it dropped the sqlite database table, but it still
> looks for it when I run v.colors. I suppose I need to manually change the
> database type.
>
> 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] v.colors usage

[Rich Shepard]

On Tue, 6 Nov 2018, Rich Shepard wrote:


db.droptable -f driver=sqlite table=stations
Forcing ...
WARNING: Deleting table  which is attached to following map(s):
WARNING: stations@mercury

but,

db.connect driver=pg database="willamette-river-hg"
GRASS 7.7.svn (willamette_basin):~/data/grassdata/willamette_basin > 
db.connect -p

driver: pg
database: willamette-river-hg


  I think I see the problem and need clarification so I can fix it.

  All prior grass projects used the default databases. This project is where
I learn how to use postgres tables instead.

  When I used db.copy I gave the postgres tables new names; e.g.,
db.copy from_driver=sqlite
from_database="$HOME/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db"
from_table=wrb to_driver=pg to_database=willamette-river-hg to_table=wrb_pg

  Now, the grass location has this directory strucure:

$ ls
PERMANENT/  db.test  mercury/  willamette-river-hg

and the mercury subdirectory has the map and attribute subdirectories:

$ ls mercury/
VAR  WIND  sqlite/  vector/  windows/

while the willamette-river-hg file is strictly attributes.

  My question is whether I can delete the ../mercury/sqlite/ subdirectory
since the pg driver is the default when I invoke grass. Then I could rename
the postgres tables to remove the _pg appended to the table names.

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

[Rich Shepard]

On Tue, 6 Nov 2018, Markus Metz wrote:


Apparently the table (not the vector map) stations exists twice: once in
the sqlite database, once in the pg willamette-river-hg database. This is
the reason for the confusion. A vector map can have a table that is not in
the default database as reported by db.connect -p.


Markus M,

  I did not realize this. I thought that using db.connect with the pg driver
would use that table exclusively. This is good to know.


db.connect as well as other db.* commands use the default database
connection reported by db.connect -p unless specified, e.g.


  Well, it didn't here when I tried using the v.colors command. :-(


You have to change the database connection for a given vector map with
v.db.connect. To be safe (avoiding confusion) you might use v.db.droptable
first. Make sure you transfer attribute values first, e.g. with db.copy.


  I had used db.copy to copy all the stations map tables to postgres except
for the stations table because that existed first in the postgres database,
and attributes there were expoorted and used with v.in.ascii to create the
grass map.

  Changing the database connection to the sqlite default I thought the
stations table was deleted:


db.droptable -f driver=sqlite table=stations

Forcing ...
WARNING: Deleting table  which is attached to following map(s):
WARNING: stations@mercury

but,


db.connect driver=pg database="willamette-river-hg"

GRASS 7.7.svn (willamette_basin):~/data/grassdata/willamette_basin > db.connect 
-p
driver: pg
database: willamette-river-hg


v.colors -c map=stations use=attr column=howmany rules=rules.txt 
rgb_col=bin_col --o

DBMI-SQLite driver error:
Error in sqlite3_prepare(): select * from stations where oid < 0
no such table: stations

DBMI-SQLite driver error:
Error in sqlite3_prepare(): select * from stations where oid < 0
no such table: stations

ERROR: Column  not found in table 


db.connect -p driver: pg database: willamette-river-hg schema: group:

GRASS 7.7.svn (willamette_basin):~/data/grassdata/willamette_basin


v.db.connect map=stations -p Vector map  is connected by: layer

<1/stations> table  in database

through driver  with key 

  So, grass tells me it dropped the sqlite database table, but it still
looks for it when I run v.colors. I suppose I need to manually change the
database type.

Regards,

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

Re: [GRASS-user] grass-user Digest, Vol 151, Issue 13

[Markos Kapes]

hank 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
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/grass-user/attachments/20181106/90cc5ea3/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Tue, 6 Nov 2018 21:54:39 +0100
> From: Markus Metz 
> To: Rich Shepard 
> Cc: grass-user 
> Subject: Re: [GRASS-user] v.colors usage
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> On Tue, Nov 6, 2018 at 5:56 PM Rich Shepard 
> wrote:
>> 
>>> On Sat, 3 Nov 2018, Rich Shepard wrote:
>>> 
>>> Where have I made the syntactical mistake?
>> 
>>   This is interesting. In the ../scripts directory, along with the grass
>> script, is a file called 'rules.txt' with perms 644. Adding a rules=
> option
>> to the v.colors command removed the rgb_col data type error and replaced
> it
>> with two errors: 1) not finding a column in the table and 2) an inability
> to
>> read the rules.txt file:
>> 
>> v.colors -c map=stations use=attr column=howmany rules=rules.txt
> rgb_col=bin_col --o
>> 
>> ERROR: Column  not found in table 
>> 
> /home/rshepard/documents/white-papers/geochemistry/willamette-river-mercury/scripts/grass-display-sample-sites.sh:
>> line 12: /scripts/rules.txt: No such file or directory
>> 
>>   For error 1:
>> 
>>> db.describe tab=stations
>>   ...
>> column:howmany
>> description:
>> type:INTEGER
>> len:4
>> scale:0
>> precision:0
>> default:
>> nullok:yes
>> select:?
>> update:?
>> 
>>   For error 2:
>> $ ll rules.txt
>> -rw-r--r-- 1 rshepard users 187 Nov  6 08:34 rules.txt
>> 
>>   What might be going on here with 7.7.svn (r73645)?
> 
> Please check v.db.connect map=stations -p
> and
> db.connect -p
> 
> Is the table attached to the map stations really in the default database?
> 
> Markus M
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/grass-user/attachments/20181106/cebd44cf/attachment-0001.html>
> 
> --
> 
> Message: 3
> Date: Tue, 6 Nov 2018 17:59:22 -0300
> From: Jamille Haarloo 
> To: GRASS user list 
> Subject: [GRASS-user] Vector points behaving strangely after using
>v.what.vect
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello all,
> 
> I created a vector points map in Grass with information on ecosystem
> characteristics based on vari

Re: [GRASS-user] v.colors usage

[Markus Metz]

On Tue, Nov 6, 2018 at 10:34 PM Rich Shepard 
wrote:
>
> On Tue, 6 Nov 2018, Markus Metz wrote:
>
> > Please check v.db.connect map=stations -p
> > and
> > db.connect -p
> > Is the table attached to the map stations really in the default
database?
>
> Markus M,
>
> > db.connect -p
> driver: pg
> database: willamette-river-hg
> schema: group:
>
>Well, well, well. Here's the problem:
>
> > v.db.connect map=stations -p
> Vector map  is connected by:
> layer <1/stations> table  in database
> 
> through driver  with key 
>
>How can stations be seen in the default sqlite database when db.connect
> shows the table in the postgres database? What else is db.connect doing if
> it allows grass commands to ignore what it reports and defaults to the
> sqlite one?

Apparently the table (not the vector map) stations exists twice: once in
the sqlite database, once in the pg willamette-river-hg database. This is
the reason for the confusion.

A vector map can have a table that is not in the default database as
reported by db.connect -p.
>
>I thought db.connect used the database to which it reported being
> connected.

db.connect as well as other db.* commands use the default database
connection reported by db.connect -p unless specified, e.g.

db.describe tab=stations driver=sqlite
database=/home/rshepard/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db

>
>How do I remove the sqlite stations table so grass sees it in the
> connected postgres database?

You have to change the database connection for a given vector map with
v.db.connect. To be safe (avoiding confusion) you might use v.db.droptable
first. Make sure you transfer attribute values first, e.g. with db.copy.

Markus M
___
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 Tue, 6 Nov 2018, Markus Metz wrote:


Please check v.db.connect map=stations -p
and
db.connect -p



Is the table attached to the map stations really in the default database?


Markus M,

  When I run db.colums without specifying the driver does grass display the
columns in the sqlite or postgres table?


db.columns table=stations

site_nbr
site_name
lon
lat
easting
northing
start_date
end_date
howmany
bin_col

  Adding the driver 'sqlite' suggests that db.columns sees the postgres
table:

db.columns table=stations driver=sqlite
WARNING: Table  not found in database  using
 driver 

So, if the db.* modules look in the postgres database tables, why does the
v.db.* modules look in the sqlite table instead? And, trying to rewire the
attribute table for the stations map from sqlite to postgres fails:


v.db.connect map=stations driver=pg table=stations -o

ERROR: Column  not found in table 

  All suggestions welcome.

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

[Rich Shepard]

On Tue, 6 Nov 2018, Markus Metz wrote:


Please check v.db.connect map=stations -p
and
db.connect -p
Is the table attached to the map stations really in the default database?


Markus M,


db.connect -p

driver: pg
database: willamette-river-hg
schema: group:

  Well, well, well. Here's the problem:


v.db.connect map=stations -p

Vector map  is connected by:
layer <1/stations> table  in database

through driver  with key 

  How can stations be seen in the default sqlite database when db.connect
shows the table in the postgres database? What else is db.connect doing if
it allows grass commands to ignore what it reports and defaults to the
sqlite one?

  I thought db.connect used the database to which it reported being
connected.

  How do I remove the sqlite stations table so grass sees it in the
connected postgres database?

Thanks!

Rich


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

[GRASS-user] Vector points behaving strangely after using v.what.vect

[Jamille Haarloo]

Hello all,

I created a vector points map in Grass with information on ecosystem
characteristics based on various sources. This was to be used as input to
create a training-set of a vector segment map with statistics for
classification.
I tried to copy the cat- values of the segments to the points- map based on
location as intermediate step by using v.what.vect. But this was not
successful - Not all cat- values of the points vector map was updated,
about 70% was. I tried then to update another (empty) column with the
segment cat-values which also worked partially - it worked for most of the
remaining which is about 25% of the total records and for non of the 70%.
Now I notice that the records of the updated cat-values are behaving
strangely. I can see the points in the map display, but if I highlight them
in the table they are not highlighted in the map display. When I click to
zoom to highlighted feature, I end-up somewhere else where it shouldn't be.
Also when I try to extract, copy or export the data, there seems to be
disconnect between the attribute values and the location of the points.
This happens with the ones of which the cat-values was updated, about 70%
of the records. When simply displayed, without other operations, it looks
fine and complete.

Is there a way to repair this disconnect?

Best,
Jamille
___
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 Tue, Nov 6, 2018 at 5:56 PM Rich Shepard 
wrote:
>
> On Sat, 3 Nov 2018, Rich Shepard wrote:
>
> >  Where have I made the syntactical mistake?
>
>This is interesting. In the ../scripts directory, along with the grass
> script, is a file called 'rules.txt' with perms 644. Adding a rules=
option
> to the v.colors command removed the rgb_col data type error and replaced
it
> with two errors: 1) not finding a column in the table and 2) an inability
to
> read the rules.txt file:
>
> v.colors -c map=stations use=attr column=howmany rules=rules.txt
rgb_col=bin_col --o
>
> ERROR: Column  not found in table 
>
/home/rshepard/documents/white-papers/geochemistry/willamette-river-mercury/scripts/grass-display-sample-sites.sh:
> line 12: /scripts/rules.txt: No such file or directory
>
>For error 1:
>
> > db.describe tab=stations
>...
> column:howmany
> description:
> type:INTEGER
> len:4
> scale:0
> precision:0
> default:
> nullok:yes
> select:?
> update:?
>
>For error 2:
> $ ll rules.txt
> -rw-r--r-- 1 rshepard users 187 Nov  6 08:34 rules.txt
>
>What might be going on here with 7.7.svn (r73645)?

Please check v.db.connect map=stations -p
and
db.connect -p

Is the table attached to the map stations really in the default database?

Markus M
___
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 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
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass7.4.1 vs 7.4.2 confusion - cannot update

[Markus Neteler]

On Tue, Nov 6, 2018 at 7:38 PM david adam  wrote:
>
> I'm trying to upgrade from Fedora 28 to 29; grass packages appear to be 
> blocking me.  relevant messages are:
>
> sudo dnf update
> [sudo] password for david:
> Failed to synchronize cache for repo 'neteler-QGIS-2.18-Las-Palmas', 
> disabling.
> Failed to synchronize cache for repo 'neteler-grass72', disabling.
> Last metadata expiration check: 0:30:15 ago on Tue 06 Nov 2018 07:51:41 AM 
> PST.
> Dependencies resolved.
>
>  Problem 1: cannot install the best update candidate for package 
> grass-7.4.1-6.fc28.x86_64
>   - nothing provides liblaszip.so.8()(64bit) needed by 
> grass-7.4.2-1.fc28.x86_64

You need to also enable the liblas repo:

dnf copr enable neteler/liblas
dnf copr enable neteler/laszip
dnf update

Then it should work. I have updated the COPR [1] page accordingly.

[1] https://copr.fedorainfracloud.org/coprs/neteler/grass74/

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

[GRASS-user] grass7.4.1 vs 7.4.2 confusion - cannot update

[david adam]

I'm trying to upgrade from Fedora 28 to 29; grass packages appear to be 
blocking me.  relevant messages are:


sudo dnf update
[sudo] password for david:
Failed to synchronize cache for repo 'neteler-QGIS-2.18-Las-Palmas', 
disabling.

Failed to synchronize cache for repo 'neteler-grass72', disabling.
Last metadata expiration check: 0:30:15 ago on Tue 06 Nov 2018 07:51:41 
AM PST.

Dependencies resolved.

 Problem 1: cannot install the best update candidate for package 
grass-7.4.1-6.fc28.x86_64
  - nothing provides liblaszip.so.8()(64bit) needed by 
grass-7.4.2-1.fc28.x86_64
 Problem 2: package grass-gui-7.4.2-1.fc28.x86_64 requires grass = 
7.4.2-1.fc28, but none of the providers can be installed
  - cannot install the best update candidate for package 
grass-gui-7.4.1-6.fc28.x86_64
  - nothing provides liblaszip.so.8()(64bit) needed by 
grass-7.4.2-1.fc28.x86_64

 Problem 3: problem with installed package grass-7.4.1-6.fc28.x86_64
  - package grass-7.4.1-6.fc28.x86_64 requires grass-libs(x86-64) = 
7.4.1-6.fc28, but none of the providers can be installed
  - package grass-7.4.1-6.fc28.x86_64 requires 
libgrass_arraystats.7.4.1.so()(64bit), but none of the providers can be 
installed
  - cannot install both grass-libs-7.4.2-1.fc28.x86_64 and 
grass-libs-7.4.1-6.fc28.x86_64
  - cannot install both grass-libs-7.4.1-6.fc28.x86_64 and 
grass-libs-7.4.2-1.fc28.x86_64
  - cannot install the best update candidate for package 
grass-libs-7.4.1-6.fc28.x86_64
  - nothing provides liblaszip.so.8()(64bit) needed by 
grass-7.4.2-1.fc28.x86_64

 Problem 4: problem with installed package grass-gui-7.4.1-6.fc28.x86_64
  - package grass-gui-7.4.1-6.fc28.x86_64 requires grass = 
7.4.1-6.fc28, but none of the providers can be installed
  - package grass-7.4.1-6.fc28.x86_64 requires grass-libs(x86-64) = 
7.4.1-6.fc28, but none of the providers can be installed
  - package grass-7.4.1-6.fc28.x86_64 requires 
libgrass_arraystats.7.4.1.so()(64bit), but none of the providers can be 
installed
  - cannot install both grass-libs-7.4.2-1.fc28.x86_64 and 
grass-libs-7.4.1-6.fc28.x86_64
  - cannot install both grass-libs-7.4.1-6.fc28.x86_64 and 
grass-libs-7.4.2-1.fc28.x86_64
  - package grass-devel-7.4.2-1.fc28.x86_64 requires grass-libs(x86-64) 
= 7.4.2-1.fc28, but none of the providers can be installed
  - package grass-gui-7.4.2-1.fc28.x86_64 requires grass = 
7.4.2-1.fc28, but none of the providers can be installed
  - cannot install the best update candidate for package 
grass-devel-7.4.1-6.fc28.x86_64
  - nothing provides liblaszip.so.8()(64bit) needed by 
grass-7.4.2-1.fc28.x86_64


Am I using the wrong repositories?  Any suggestions welcomed! TIA

___
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 Sat, 3 Nov 2018, Rich Shepard wrote:


 Where have I made the syntactical mistake?


  This is interesting. In the ../scripts directory, along with the grass
script, is a file called 'rules.txt' with perms 644. Adding a rules= option
to the v.colors command removed the rgb_col data type error and replaced it
with two errors: 1) not finding a column in the table and 2) an inability to
read the rules.txt file:

v.colors -c map=stations use=attr column=howmany rules=rules.txt 
rgb_col=bin_col --o

ERROR: Column  not found in table 
/home/rshepard/documents/white-papers/geochemistry/willamette-river-mercury/scripts/grass-display-sample-sites.sh:
line 12: /scripts/rules.txt: No such file or directory

  For error 1:


db.describe tab=stations

  ...
column:howmany
description:
type:INTEGER
len:4
scale:0
precision:0
default:
nullok:yes
select:?
update:?

  For error 2:
$ ll rules.txt 
-rw-r--r-- 1 rshepard users 187 Nov  6 08:34 rules.txt


  What might be going on here with 7.7.svn (r73645)?

Rich



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

Re: [GRASS-user] v.colors: color rules

[Rich Shepard]

On Tue, 6 Nov 2018, Moritz Lennert wrote:


No. Please read the r.colors man page for an explanation of the rules.


Moritz,

  I must have missed the implications when I read them.


If you want 1 - 10 in the same color, you have to do this:

1 231:00:00
10 231:00:00
11 89:00:00
20 89:00:00
etc


  Thank you.

Regards,

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

Re: [GRASS-user] v.colors: color rules

[Moritz Lennert]

On 06/11/18 17:10, Rich Shepard wrote:

Examples of rules with the v.colors module show single digits and
percentages. Will the module read a file that has a range of values to which
a color is assigned?

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



No. Please read the r.colors man page for an explanation of the rules.

If you want 1 - 10 in the same color, you have to do this:

1 231:00:00
10 231:00:00
11 89:00:00
20 89:00:00
etc

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

[GRASS-user] v.colors: color rules

[Rich Shepard]

  Examples of rules with the v.colors module show single digits and
percentages. Will the module read a file that has a range of values to which
a color is assigned?

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

TIA,

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

[GRASS-user] v.colors2?

[Rich Shepard]

  There is an extension called v.colors2 but all references on the manual
page are to v.colors. While I've not compared the two manual pages
side-by-side the '2' version looks just like the original.

  What are the differences between the two modules?

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

[Frank David]

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


Regards,
Frank

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

Re: [GRASS-user] GRASS 7.4.2 make error

[Thomas Adams]

Hi Markus!

Thank you -- that was it. Odd, though, I've used these options many time
previously without this error; live and learn!

Best,
Tom

On Tue, Nov 6, 2018 at 9:12 AM Markus Neteler  wrote:

> Hi Thomas,
>
> On Tue, Nov 6, 2018 at 2:42 PM Thomas Adams  wrote:
> >
> > Hi all:
> >
> > I'm trying to make GRASS 7.4.2 from source on Ubuntu 16.04. I've built
> GRASS from source many times but I am seeing this error:
> >
> > include/Make/Vars.make:1: include/Make/Platform.make: No such file or
> directory
> > make: *** No rule to make target 'include/Make/Platform.make'.  Stop.
> >
> > My configure options look like this:
> > ./configure  --enable-64bit --with-libs=/usr/lib/x86_64-linux-gnu
> --with-cxx --enable-largefile=yes --with-nls --with-readline --with-pthread
> --with-proj-share=/usr/local/share/proj/
> --with-geos=/usr/local/bin/geos-config
> --with-wxwidgets=/usr/local/bin/wx-config --with-cairo
> --with-opengl-libs=/usr/include/GL --with-freetype=yes
> --with-freetype-includes=/usr/include/freetype2/ --with-postgres=yes
> --with-postgres-includes=/usr/include/postgresql --with-sqlite=yes
> --with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-odbc=no
> --with-blas --with-lapack --with-liblas=yes
> --with-liblas-config=/usr/bin/liblas-config
> --with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/lib/libblas
> --with-lapack-includes=/usr/include --with-lapack-libs=/usr/lib
> --with-blas-includes=/usr/include --no-create --no-recursion
>
> What is the purpose of
>
> sh configure --help | grep no-create -
>   --no-create do not create output files
>
> ? (I have never seen that being used...)
>
> Maybe that's the issue?
>
> Markus
>


-- 
Thomas E Adams, III
1724 Sage Lane
Blacksburg, VA 24060
tea...@gmail.com (personal)
t...@terrapredictions.org (work)

1 (513) 739-9512 (cell)
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7.4.2 make error

[Markus Neteler]

Hi Thomas,

On Tue, Nov 6, 2018 at 2:42 PM Thomas Adams  wrote:
>
> Hi all:
>
> I'm trying to make GRASS 7.4.2 from source on Ubuntu 16.04. I've built GRASS 
> from source many times but I am seeing this error:
>
> include/Make/Vars.make:1: include/Make/Platform.make: No such file or 
> directory
> make: *** No rule to make target 'include/Make/Platform.make'.  Stop.
>
> My configure options look like this:
> ./configure  --enable-64bit --with-libs=/usr/lib/x86_64-linux-gnu --with-cxx 
> --enable-largefile=yes --with-nls --with-readline --with-pthread 
> --with-proj-share=/usr/local/share/proj/ 
> --with-geos=/usr/local/bin/geos-config 
> --with-wxwidgets=/usr/local/bin/wx-config --with-cairo 
> --with-opengl-libs=/usr/include/GL --with-freetype=yes 
> --with-freetype-includes=/usr/include/freetype2/ --with-postgres=yes 
> --with-postgres-includes=/usr/include/postgresql --with-sqlite=yes 
> --with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-odbc=no 
> --with-blas --with-lapack --with-liblas=yes 
> --with-liblas-config=/usr/bin/liblas-config 
> --with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/lib/libblas 
> --with-lapack-includes=/usr/include --with-lapack-libs=/usr/lib 
> --with-blas-includes=/usr/include --no-create --no-recursion

What is the purpose of

sh configure --help | grep no-create -
  --no-create do not create output files

? (I have never seen that being used...)

Maybe that's the issue?

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

Re: [GRASS-user] Semi-automatic classification of old thematic map

[Nikos Alexandris]

* Giuseppe Cillis  [2018-11-06 11:23:56 +0100]:


Dear all,
I would like to classify in a semi-automatic way, an old scanned thematic
map of land use.
The different classes of land use are represented by polygons of different
colors.
Which module can I use to identify the different land use classes?
Thanks


Dear Giuseppe,

have a look at
https://grasswiki.osgeo.org/wiki/Image_classification#Supervised_classification.

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

Re: [GRASS-user] v.colors usage [UPDATE]

[Rich Shepard]

On Tue, 6 Nov 2018, st_kie...@web.de wrote:


Are there any entries in the table with bin_col is empty, i.e. null? I am
not sure in this context, but I know from other cases that database driver
failed in recognizing the datatype of a field while checking the first
dataset in the table and the field was not set (i.e. null).


Stefan,

  No. There are only 82 rows in the table and the update command applied to
all rows, grouped first by 'site_nbr', then by the range of values in the
'howmany' column.

  I just checked (again) and every row has an entry for each column. Thanks
for the thought,

Best regards,

Rich



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

[GRASS-user] GRASS 7.4.2 make error

[Thomas Adams]

Hi all:

I'm trying to make GRASS 7.4.2 from source on Ubuntu 16.04. I've built
GRASS from source many times but I am seeing this error:

include/Make/Vars.make:1: include/Make/Platform.make: No such file or
directory
make: *** No rule to make target 'include/Make/Platform.make'.  Stop.

My configure options look like this:
./configure  --enable-64bit --with-libs=/usr/lib/x86_64-linux-gnu
--with-cxx --enable-largefile=yes --with-nls --with-readline --with-pthread
--with-proj-share=/usr/local/share/proj/
--with-geos=/usr/local/bin/geos-config
--with-wxwidgets=/usr/local/bin/wx-config --with-cairo
--with-opengl-libs=/usr/include/GL --with-freetype=yes
--with-freetype-includes=/usr/include/freetype2/ --with-postgres=yes
--with-postgres-includes=/usr/include/postgresql --with-sqlite=yes
--with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-odbc=no
--with-blas --with-lapack --with-liblas=yes
--with-liblas-config=/usr/bin/liblas-config
--with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/lib/libblas
--with-lapack-includes=/usr/include --with-lapack-libs=/usr/lib
--with-blas-includes=/usr/include --no-create --no-recursion

Running configure completes without errors.

I use the default install location /usr/local

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

Re: [GRASS-user] g.message in python not working

[Micha Silver]

  
  

On 11/6/18 2:17 PM, Moritz Lennert
  wrote:

On
  06/11/18 12:36, Micha Silver wrote:
  
  
  
  
  I can confirm this behaviour in the 7.4.2 Debian testing package.
  Please post a ticket. It works as expected in 7.6 and trunk.
  
  
  Moritz
  



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


Thanks,

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

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

Re: [GRASS-user] Semi-automatic classification of old thematic map

[Moritz Lennert]

On 06/11/18 13:38, Markus Neteler wrote:

Hi,

On Tue, Nov 6, 2018 at 11:24 AM Giuseppe Cillis  wrote:


Dear all,
I would like to classify in a semi-automatic way, an old scanned thematic map 
of land use.
The different classes of land use are represented by polygons of different 
colors.
Which module can I use to identify the different land use classes?


In this case it might make sense to apply OBIA techniques:

https://grasswiki.osgeo.org/wiki/Image_classification#Object-based_classification_and_image_segmentation

After segmentation, classification methods can be applied.
Of course there may be other approaches as well.


Next to the info given by Markus, you could also try i.superpixels.slic 
to segment the map.


If the colors of the different classes are very homogeneous internally 
and you do not have to many land use classes, you could also do a simple 
manual reclassification using r.mapcalc (assuming here that your scanned 
map is imported as three bands red, green and blue):


if(map.red > 10 && map.res < 15 && map.green > 55 && map.green < 70 [etc],
1, # classify as class 1
if([add rules], # else
2,
if([add rules] # else
etc.

To homogenize your objects, you could also try to regroup very similar 
(but not strictly identical) adjacent pixels into objects using r.clump 
with the threshold parameter and then recreate homogenized red, green 
and blue bands by calculating the mean of each band in each clump using 
r.stats.zonal and then use some rule system as above, or some supervised 
technique such as r.learn.ml or its OBIA equivalents to classify.


Moritz


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

Re: [GRASS-user] Semi-automatic classification of old thematic map

[Markus Neteler]

Hi,

On Tue, Nov 6, 2018 at 11:24 AM Giuseppe Cillis  wrote:
>
> Dear all,
> I would like to classify in a semi-automatic way, an old scanned thematic map 
> of land use.
> The different classes of land use are represented by polygons of different 
> colors.
> Which module can I use to identify the different land use classes?

In this case it might make sense to apply OBIA techniques:

https://grasswiki.osgeo.org/wiki/Image_classification#Object-based_classification_and_image_segmentation

After segmentation, classification methods can be applied.
Of course there may be other approaches as well.

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

Re: [GRASS-user] g.message in python not working

[Moritz Lennert]

On 06/11/18 12:36, Micha Silver wrote:
Is there any change in the way g.message works under python between 
GRASS 7.4.0 and 7.4.2? I am not getting any message output. (python 
"print" and "cat" statements work as expected). The script printed 
messages fine in 7.4.0.



I see the usual result at a shell prompt:


GRASS 7.4.2 (ITM):~ > g.message "Hello"

Hello
GRASS 7.4.2 (ITM):~ > g.message -w "Hello"
WARNING: Hello


However in a python script no output:


GRASS 7.4.2 (ITM):~ > ipython2

Python 2.7.12 (default, Dec  4 2017, 14:50:18)
Type "copyright", "credits" or "license" for more information.

IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import grass.script as gs
In [2]: gs.message("Hello")
In [3]: gs.warning("Hello")
In [4]: print("Hello")
Hello


I can confirm this behaviour in the 7.4.2 Debian testing package. Please 
post a ticket. It works as expected in 7.6 and trunk.


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

[GRASS-user] g.message in python not working

[Micha Silver]

  
  
Is there any change in the way g.message works under python
  between GRASS 7.4.0 and 7.4.2? I am not getting any message
  output. (python "print" and "cat" statements work as expected).
  The script printed messages fine in 7.4.0.



I see the usual result at a shell prompt:

  
GRASS 7.4.2 (ITM):~ > g.message "Hello"
Hello
  GRASS 7.4.2 (ITM):~ > g.message -w "Hello"
  WARNING: Hello


However in a python script no output:

  
GRASS 7.4.2 (ITM):~ > ipython2 
Python 2.7.12 (default, Dec  4 2017, 14:50:18) 
  Type "copyright", "credits" or "license" for more
information.
  
  IPython 5.1.0 -- An enhanced Interactive Python.
  ? -> Introduction and overview of IPython's
features.
  %quickref -> Quick reference.
  help  -> Python's own help system.
  object?   -> Details about 'object', use 'object??'
for extra details.
  
  In [1]: import grass.script as gs
  In [2]: gs.message("Hello")
  In [3]: gs.warning("Hello")
  In [4]: print("Hello")
Hello


Thanks

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

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

[GRASS-user] Semi-automatic classification of old thematic map

[Giuseppe Cillis]

Dear all,
I would like to classify in a semi-automatic way, an old scanned thematic
map of land use.
The different classes of land use are represented by polygons of different
colors.
Which module can I use to identify the different land use classes?
Thanks

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

Re: [GRASS-user] From Vector to raster

[Moritz Lennert]

On 06/11/18 09:34, francesco sapienza wrote:
Hello! i'm having problems in the simple task of convert a vector to a 
raster. I have obteined my vector polygon starting from 2d points in my 
map (v.hull) i can see the new polygon and now i want to create a raster 
with "1" values inside the area and null values outside. I used 
[v.to.rast] to do that, specifing as input feature type only area and as 
raster value (for use=val) "1". Everything seems to work but when i 
question the map i find that both inside and outside my polygon instead 
than "0" and "1" i have "no values"

(must say that im a beginner). thanks a lot for the help!!


You probably have to set the computational region first. This determines 
the grid in which any new raster is written, both its extent and its 
resolution (see [1] for a bit more information).


Depending on the size of the area covered and the resolution desired, 
you can use something like this:


g.region vect=YourPolygon res=YourDesiredResolution [-a if you want to 
make sure to get precisely this resolution, and have the extents widened 
to fit to this resolution  - see g.region manual page for details]


Then try v.to.rast.

Moritz


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

[GRASS-user] From Vector to raster

[francesco sapienza]

Hello! i'm having problems in the simple task of convert a vector to a
raster. I have obteined my vector polygon starting from 2d points in my map
(v.hull) i can see the new polygon and now i want to create a raster with
"1" values inside the area and null values outside. I used [v.to.rast] to
do that, specifing as input feature type only area and as raster value (for
use=val) "1". Everything seems to work but when i question the map i find
that both inside and outside my polygon instead than "0" and "1" i have "no
values"
(must say that im a beginner). thanks a lot for the help!!
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.colors usage [UPDATE]

[st_kiefer]

Hi Rich,
are there any entries in the table with bin_col is empty, i.e. null? I am not 
sure in this context, but I know from other cases that database driver failed 
in recognizing the datatype of a field while checking the first dataset in the 
table and the field was not set (i.e. null).

Regards.

Stefan

> Rich Shepard  hat am 6. November 2018 um 00:02 
> geschrieben:
> 
> 
> 
> On Sat, 3 Nov 2018, Rich Shepard wrote:
> 
> >> v.colors -c map=stations use=attr column=site_nbr rgb_col=bin_col --o
> > Writing color rules...
> > ERROR: Data type of RGB column  must be char
> >
> >  Where have I made the syntactical mistake?
> 
>I slightly modified the command to use a different column:
> > v.colors -c map=stations use=attr column=howmany rgb_col=bin_col --o
> Writing color rules...
> ERROR: Data type of RGB column  must be char
> 
> Checking that grass saw the postgres table:
> > db.connect -p
> driver: pg
> database: willamette-river-hg
> schema: 
> group:
> 
> Yep, it does.
> 
> Looking at the table structure:
> 
> > db.describe table=stations
> table:stations
> description:
> insert:?
> delete:?
> ncols:10
> nrows:82
>...
> 
> column:howmany
> description:
> type:INTEGER
> len:4
> scale:0
> precision:0
> default:
> nullok:yes
> select:?
> update:?
> 
> column:bin_col
> description:
> type:CHARACTER
> len:12
> scale:0
> precision:0
> default:
> nullok:yes
> select:?
> update:?
> 
>So, why does grass tell me the bin_col column needs to be CHAR when it is
> (unless grass differentiates between char and CHARACTER.)
> 
> 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