The postgres table with station data has data type varchar(12) for the
column named bin_col but grass apparently doesn't see this:
# \d stations
...
bin_col | character varying(12)
# select bin_col from stations limit 3;
bin_col ----------
0:231:57
(3 rows)
v.colors -c map=stations use=attr column=site_nbr rgb_col=bin_col --o
Writing color rules...
ERROR: Data type of RGB column <bin_col> must be char
Where have I made the syntactical mistake?
TIA,
Rich
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 <bin_col> must be charWhere 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 <bin_col> 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
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 <rshepard@appl-ecosys.com> 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 <bin_col> 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 <bin_col> must be charChecking 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
On Tue, 6 Nov 2018, st_kiefer@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
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 <howmany> not found in table <stations>
/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
On Tue, Nov 6, 2018 at 5:56 PM Rich Shepard <rshepard@appl-ecosys.com> 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 directoryFor 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
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 <stations> not found in database <willamette-river-hg> using
driver <sqlite>
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 <cat> not found in table <stations>
All suggestions welcome.
Regards,
Rich