[GRASSLIST:376] Re: GRASS 6.1CVS v.in.ascii problem

David,

When I use the correct syntax:

v.in.ascii input=/home/adams/locations.txt output=locs_new format=point fs="|" columns='x double precision,y double precision,z double precision,id int' x=1 y=2 z=3 cat=0

I get a memory fault with GRASS 6.1CVS; again, with GRASS 6.0.2 I have no problems.

Regards,
Tom

David Finlayson wrote:

I recall there have been discussions about this (GUI) issue before. If
this is still in the latest CVS version, report it as a bug. Mike has
been working hard on the GUI to fix these things.

David

On 3/24/06, Thomas.Adams@noaa.gov <Thomas.Adams@noaa.gov> wrote:
  

David,

Yes, you are correct. But, understand that I simply copied and pasted from the GRASS GUI --
I did not do any
editing. I'll try with the correct syntax tomorrow... actually, I have been through this before.
The problem is
(really) that using v.in.ascii through the GRASS GUI, still fails for me with GRASS 6.1CVS, but
works with GRASS
6.0.2.

Thanks again for your help...

Tom

----- Original Message -----
From: David Finlayson <david.p.finlayson@gmail.com>
Date: Friday, March 24, 2006 3:41 pm
Subject: Re: GRASS 6.1CVS v.in.ascii problem

This command has two syntax errors in it:

v.in.ascii input=/home/adams/locations.txt output=locs_new
        

format=point> fs=| 'columns=x double precision,y double precision,z
double> precision,id int' x=1 y=2 z=3 cat=0

it should be:

v.in.ascii input=/home/adams/locations.txt output=locs_new
        

format=point> fs="|" columns='x double precision,y double
precision,z double
      

precision,id int' x=1 y=2 z=3 cat=0
        

Note the position of the quotes in both the "fs" and the "columns"
options. I don't think you can use a pipe character without quoting it
(I don't know about single or double quotes. Try both) and the columns
argument has the quote in the wrong place altogether.

- David

On 3/24/06, Thomas Adams <Thomas.Adams@noaa.gov> wrote:
      

David,

Very interesting. Here are the facts:

Using a RedHat Linux system

Both v.in.ascii and v.proj (from lat-long location to LCC
        

location) work
      

fine with GRASS 6.0.2 built from source.

Using GRASS 6.1CVS (dated 2006-03-18) built from source v.proj (now)
works, but did not with the 2006-03-04 CVS build; v.in.ascii does
        

NOT> work -- I get errors:
      

WARNING: Unparsable LatLong value found:
         -80.04916667|39.56444444|860|49450586
WARNING: Unparsable LatLong value found:
         -84.82388889|38.705|0|49450588
WARNING: Unparsable LatLong value found:
         -88.50583333|39.35944444|0|49450598
WARNING: Unparsable LatLong value found:
         -81.20388889|39.56305556|0|49450600
WARNING: Unparsable LatLong value found:
         -82.17777778|41.34416667|0|49450616
WARNING: Unparsable LatLong value found:
         -84.95972222|39.73305556|0|113805417
WARNING: Unparsable LatLong value found:
         -82.92166667|40.35666667|901|113805418
WARNING: Unparsable LatLong value found:
         -85.15833333|39.57361111|850|113805424
WARNING: Unparsable LatLong value found:
         -80.64666667|37.72777778|1600|113805425

My ascii data file looks like:

-80.04916667|39.56444444|860|49450586
-84.82388889|38.705|0|49450588
-88.50583333|39.35944444|0|49450598
-81.20388889|39.56305556|0|49450600
-82.17777778|41.34416667|0|49450616
-84.95972222|39.73305556|0|113805417
-82.92166667|40.35666667|901|113805418
-85.15833333|39.57361111|850|113805424
-80.64666667|37.72777778|1600|113805425
-85.71666667|35.43166667|0|113805426
-86.38055556|36.89527778|500|113805427
-81.24583333|37.49416667|3100|113805430
-83.63833333|40.65805556|997|113805432
-81.71027778|38.18055556|622|113805434
-85.04916667|41.36|861.7|49460912
-85.67944444|40.30833333|880|113805437
-80.76166667|37.475|2159|113805438

The GRASS 6.0.2 interface generated v.in.ascii command with
        

output looks
      

like:

v.in.ascii input=/home/adams/locations.txt output=locs_new
        

format=point> fs=| 'columns=x double precision,y double precision,z
double> precision,id int' x=1 y=2 z=3 cat=0
      

Maximum input row length: 42
Maximum number of columns: 4
Minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
Building topology ...egistering lines: 1000 2000 3000 4000
        

5000> 5030 primitives registered
      

Building areas:

0 areas built
0 isles built
Attaching islands:
Attaching centroids:

Topology was built.

Number of nodes : 4468
Number of primitives: 5030
Number of points : 5030
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

The GRASS 6.1CVS interface generated v.in.ascii command with
        

output (not
      

including the warnings/errors, above) looks like:

v.in.ascii input=/home/adams/locations.txt output=locs_new
        

format=point> fs=| skip=0 'columns=x double precision,y double
precision,z double
      

precision,id int' x=1 y=2 z=3 cat=0
Maximum input row length: 42
Maximum number of columns: 4
Minimum number of columns: 4

That is, the comand never appears to complete...

Tom

David Finlayson wrote:
        

I've use v.in.ascii on text files almost daily and have not
experienced problems like you describe. If you can isolate the
problem, the developers would probably be very likely to fix
          

the bug.
      

This is an important module.

As an aside, I use sqlite for my attributes, not Postgres and
          

that may
      

be the difference between our experiences (though Postgres
          

seems to be
      

the "preferred" database back end for GRASS)

David

On 3/16/06, David Finlayson <david.p.finlayson@gmail.com> wrote:

If I understand you correctly, you have a table in Postgres that
happens to contain x, y coordinates in addition to other
            

attributes> >> but is not a PostGIS layer. You were able to convert
the X,Y points
      

into a GRASS vector file (points) using v.in.db AND this new
            

vector> >> file seems to work in the lat long Location.
      

Now when you try to project the new vector file into a LCC
            

location it
      

fails. What is the error you are getting? That seems like it
            

should> >> work.
      

As a test, have you tried exporting the postgres table as a
            

csv file
      

(at least pointid, x and y) and then load the vector with
            

v.in.ascii?> >> You will be able to link the ID, X,Y CSV file back
to the original
      

postgres attribute table using the ID column. Does this simple
            

vector> >> file project?
      

David

On 3/16/06, Thomas Adams <Thomas.Adams@noaa.gov> wrote:

David,

Maybe you don't understand. The Postgres table is for points
              

and has the
      

lat-long location; using v.in.db one is required to identify
              

the x,y
      

location. The additional attributes are read as well, of
              

course. I can
      

successfully import the Postgres table into GRASS into my lat-
              

long> >>> location. If I then try to re-project the points into a
LCC projection
      

(from the LCC location), the v.proj does not seem to work. Is
              

this what
      

you previously understood I was tying to do or do now?

Who would know whether or not this can be done?

Thanks for you r responses…

Tom

David Finlayson wrote:

Ah, I understand now. I'm afraid I can't help you with this.
                

I've only
      

used databases to hold attribute information not the
                

topology also. I
      

haven't tried PostGIS yet.

David

On 3/15/06, Thomas Adams <Thomas.Adams@noaa.gov> wrote:

List:

I have a Lat-Long location into which I have successfully
                  

imported> >>>>> points from Postgres (a further question about this
further below). What
      

I want to do is to re-project the points into a Lambert
                  

Conic Conformal
      

location using v.proj. When I try to do this, it does not
                  

work — it
      

seems as though GRASS does not know how to do this. I have
                  

been able to
      

do this successfully with points imported using v.in.ascii.
                  

It seems I
      

am missing something, either conceptually or procedurally…

The further question about using v.in.db, the 'key'
                  

parameter in the
      

documentation claims this is a string, which makes since to
                  

me, but when
      

v.in.db is run, GRASS complains that an integer is needed.
                  

I'm guessing
      

the integer that's supplied is the column/field number
                  

(beginning with
      

'1'); if true, this seems to be inconsistent by what the
                  

'x', 'y', and
      

'z' fields require — just a thought.

Tom

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
David Finlayson

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
David Finlayson

--
David Finlayson

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
David Finlayson

--
David Finlayson
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033