[GRASSLIST:372] GRASS 6.1CVS v.in.ascii problem
Thomas Adams
Thomas.Adams at noaa.gov
Fri Mar 24 15:25:28 EST 2006
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