[GRASSLIST:380] Re: GRASS 6.1CVS v.in.ascii problem
Michael Barton
michael.barton at asu.edu
Sat Mar 25 12:59:38 EST 2006
I had the identical thing happen the other day using 6.1 from 11 March.
I went ahead and put it into dbf format and imported it that way, but it
should have worked through v.in.ascii.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
> From: Thomas Adams <Thomas.Adams at noaa.gov>
> Date: Fri, 24 Mar 2006 15:25:28 -0500
> To: David Finlayson <david.p.finlayson at gmail.com>
> Cc: GRASSLIST <GRASSLIST at baylor.edu>
> Subject: [GRASSLIST:372] GRASS 6.1CVS v.in.ascii problem
>
> 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 at 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 at 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 at 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 at 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 at 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 at noaa.gov
>
> VOICE: 937-383-0528
> FAX: 937-383-0033
More information about the grass-user
mailing list