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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
