[GRASS-user] v.in.ascii: Error Needs Explanation

   I have a 3-column table with 110,337 rows. The first column is the primary
key to a postgres attribute table, the second column is the longitude, and
the third column is the latitude. Based on the manual page I made the field
separators the pipe '|'. However, I have a syntax error and I don't
understand what it's telling me.

   First few table lines:

well_log|longitude|latitude
24400|-117.310000|41.040000
24401|-117.410000|40.980000
24402|-117.450000|40.930000
24529|-117.080000|40.890000

   The command line is:

GRASS 6.5.svn (Nevada-ll):~/grassdata > v.in.ascii -bt
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(6), x double precision, y double
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum input row length: 29
Maximum number of columns: 3
Minimum number of columns: 1
ERROR: x column number > minimum last column number
        (incorrect field separator?)

   The manual page says:

x=integer
     Number of column used as x coordinate (points mode)
     First column is 1
     Default: 1

so I specified it as column 2, the y value as column 3, and nothing for the
primary key column. Should that be considered the cat column? Where is my
command syntax incorect?

   While I'm learning how to do this, does it matter if there are multiple
'well_log' values at the same location? I guess that multiple wells were
drilled in essentially the same place so they have the same long/lat values
but different row keys in the postgres table.

Rich

Hi Rich

On 03/03/2011 08:10 PM, Rich Shepard wrote:

  I have a 3-column table with 110,337 rows. The first column is the primary
key to a postgres attribute table, the second column is the longitude, and
the third column is the latitude. Based on the manual page I made the field
separators the pipe '|'. However, I have a syntax error and I don't
understand what it's telling me.

  First few table lines:

well_log|longitude|latitude
24400|-117.310000|41.040000
24401|-117.410000|40.980000
24402|-117.450000|40.930000
24529|-117.080000|40.890000

  The command line is:

GRASS 6.5.svn (Nevada-ll):~/grassdata > v.in.ascii -bt
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(6), x double precision, y double
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum input row length: 29
Maximum number of columns: 3
Minimum number of columns: 1
ERROR: x column number > minimum last column number
       (incorrect field separator?)

  The manual page says:

x=integer
    Number of column used as x coordinate (points mode)
    First column is 1
    Default: 1

so I specified it as column 2, the y value as column 3, and nothing for the
primary key column. Should that be considered the cat column? Where is my
command syntax incorect?

Worked for me on those few rows. My guess is that somewhere down among those 100,000 rows there's one that's either missing the '|' character. or missing the actual digits or some such.
BTW, if you're specifying the '-t' option to *not* create the attrib table, I suppose there's no need to give the column header names and types for a table that's not going to be created.

--
Micha

  While I'm learning how to do this, does it matter if there are multiple
'well_log' values at the same location? I guess that multiple wells were
drilled in essentially the same place so they have the same long/lat values
but different row keys in the postgres table.

Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

This mail was received via Mail-SeCure System.

--
Micha Silver
Arava Development Co. +972-52-3665918
http://www.surfaces.co.il

On Thu, 3 Mar 2011, Micha Silver wrote:

Worked for me on those few rows. My guess is that somewhere down among
those 100,000 rows there's one that's either missing the '|' character. or
missing the actual digits or some such.

   OK. I'll go look.

BTW, if you're specifying the '-t' option to *not* create the attrib
table, I suppose there's no need to give the column header names and types
for a table that's not going to be created.

   I had no idea what to do with the '-t' option. I added it only because the
attributes will be in a separate postgres table. But, I can leave it off
anyway.

Thanks,

Rich

On Thu, 3 Mar 2011, Micha Silver wrote:

My guess is that somewhere down among those 100,000 rows there's one
that's either missing the '|' character. or missing the actual digits or
some such.

Micha,

   It turns out there were two types of faulty rows to be eliminated. My awk
script got rid of the ones where the northings and eastings were 0.000000,
but not the ones where those columns were blank. Running grep -v removed
those lines.

Toda raba,

Rich

On Thu, 3 Mar 2011, Micha Silver wrote:

Worked for me on those few rows. My guess is that somewhere down among
those 100,000 rows there's one that's either missing the '|' character. or
missing the actual digits or some such. BTW, if you're specifying the '-t'
option to *not* create the attrib table, I suppose there's no need to give
the column header names and types for a table that's not going to be
created.

Micha,

   Turns out there were three gotcha's: zeros for easting and northing,
nothing for either, or (in a single row), an easting value but no northing
value.

   Now v.in.ascii is throwing a different error. New thread on its way.

Rich