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

Markus Neteler neteler at itc.it
Sat Mar 25 14:37:30 EST 2006


Hi,

I have debugged that and fixed a wrong memory free (wrong
position, I think) in CVS.
At least the pisted example now works for me.

Please try again,

 Markus

PS: It must have been there for long time according to ChangeLog.
Maybe you just didn't use LatLong? It apparently only happened
in LatLong.

On Sat, Mar 25, 2006 at 10:59:38AM -0700, Michael Barton wrote:
> 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
> 

-- 
Markus Neteler     <neteler itc it>       http://mpa.itc.it
ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy




More information about the grass-user mailing list