[GRASS-user] SQL Error using "v.color"

[Hamish]

actually it was missing the v.db.connect -l flag, given that it respects
the layer= setting and the grep isn't needed. (6.4svn r44634)

> To follow up on your earlier comment, submitting:
>  v.db.connect -g map=pse layer=1 fs=";"
> yields:
>  1/pse;pse;cat;C://test/poverty/sqlite.db;sqlite
> Does this help?

yes. for some reason on windows the sqlite table is given a name, and
that gets reported along with the layer number (1/name;...). So trying to
match against just the number fails. I wasn't aware of that name being
set by anything yet, although support for it has been there for a long
time. (?) shrug, "v.db.connect layer=1 -g -l" should avoid the grep now,
so just a curiosity.

Roy:
> To follow up on my problem and your fix, I am no longer
> getting the error message i used to get. When i look at the attribute
> table, however, the RGB_column variable (which i named `hc2' in my
> example) -- created by v.colors -- has a lot of missing values. Do
> you have an idea why this is the case?
...
> I tried to generate a new rgb_column using v.colors, but that did not 
> help. When I submit "v.univar map=pse column=y2009", i get:
> "number of features with non NULL attribute: 96
> number of missing attributes: 0
> number of NULL attributes: 0
> minimum: 0.0947129
> maximum: 0.388736
> range: 0.294023

I'm not sure, I'd have to experiment with it, but that will have to wait
until I get a bit of free time. maybe it is falling over on the 0-1 range?
(e.g. reducing everything to integers somewhere)


Hamish