I am able to import a CSV file containing two columns both of double
precision, but once I add in a third column (called 'name') of text with
arbitrary length, I get the following error:
"x column is not of number type"
The command I am using is as follows:
v.in.ascii input=data.csv output=incidents format=point fs=, skip=1
{columns=x double precision, y double precision, name varchar(255)} x=1 y=2
z=0 cat=0 --overwrite
There must be something in the text that v.in.ascii does not like. FWIW,
this third column contains street addresses. What could be causing this?
I am able to import a CSV file containing two columns both of double
precision, but once I add in a third column (called 'name') of text with
arbitrary length, I get the following error:
"x column is not of number type"
The command I am using is as follows:
v.in.ascii input=data.csv output=incidents format=point fs=, skip=1
{columns=x double precision, y double precision, name varchar(255)}
x=1 y=2 z=0 cat=0 --overwrite
There must be something in the text that v.in.ascii does not like. FWIW,
this third column contains street addresses. What could be causing this?
maybe a comma in the street address is confusing it? Can you export with
another field separator like "|"?
or turn on full debug messages:
g.gisenv set="DEBUG=5"
and rerun. Set it back to 0 to get no messages.
Solved:
This may be a bug, or something that could/should be improved (maybe it
already has been...I'm using 6.3RC6). There were missing values in the x and
y columns because there were some addresses that could not be geocoded and
grass did not know what to do when it encountered a blank cell. Ignoring the
row, and displaying a warning to the user with the row number may be better
IMO.
Thanks again!
Ryan
hamish_b wrote:
or turn on full debug messages:
g.gisenv set="DEBUG=5"
and rerun. Set it back to 0 to get no messages.
On Mon, Sep 15, 2008 at 6:55 AM, Ryan R. Rosario <uclamathguy@gmail.com> wrote:
The debug option helped quite a bit.
Solved:
This may be a bug, or something that could/should be improved (maybe it
already has been...I'm using 6.3RC6). There were missing values in the x and
y columns because there were some addresses that could not be geocoded and
grass did not know what to do when it encountered a blank cell. Ignoring the
row, and displaying a warning to the user with the row number may be better
IMO.
In r.in.xyz I had implemented exactly this (in my case, to avoid that
super long
Lidar files were refused due to a broken last line which only
contained a strange
symbol):
-i Ignore broken lines
They are printed as warning, though, so that the user knows what's going on.
Maybe we want this in v.in.ascii, too.