[GRASSLIST:376] Re: GRASS 6.1CVS v.in.ascii problem
Thomas Adams
Thomas.Adams at noaa.gov
Sat Mar 25 07:37:36 EST 2006
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 at noaa.gov <Thomas.Adams at 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 at 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 at 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 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
>>>>
>>>>
>>>>
>>> --
>>> 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