[GRASSLIST:7702] Re: v.in.ascii

[Ian MacMillan]

Dave I am not sure if this helps, but here are my thoughts.  I hate to 
say this but "command not found" sounds like a typo error to me (that 
is what I tend to get a lot anyway).  Check that you spelled everything 
correctly.

Also, did you use v.in.ascii in a lat-long location, or in a 
meter-based location (like UTM)?  after running

g.region vect=your_vect -p

what are the results?

Also, what is the exact error when running d.vect your_vect?

Cheers,
Ian

On Jul 23, 2005, at 7:23 AM, David Kindem wrote:

> I'm still struggling a bit with this.  I have a text file with the 
> following site information:
>
> -85.74792719|42.98678484
>
> I use v.in.ascii to generate a vector layer. When I try to display it 
> in my location, I receive an error ("command not found").
>
> If I set use g.region to set the region to match the vector layer, my 
> point displays.  Using g.where to identify the location, I get:
>
> EAST:             NORTH:               LON:               LAT:
>       -85.76293174        42.98644948       -91.48951223         
> 0.00038771
>
> So it seems that Grass is trying to interpret my decimal degree 
> locations as northing and easting data.  Does that seem to be the 
> case?  If so, do I need to include additional parameters in v.in.ascii 
> to get the software to recognize decimal degrees?
>
> Thanks for any suggestions.
>
> Dave 
>
> On Jul 18, 2005, at 2:35 AM, Hamish wrote:
>
>> Dave:
>>
>>> I'm attempting to us v.in.ascii to import sites. Things work fine
>>> when I use Eastings/Northings. However, I would like to import
>>> points in latitude/longiture. When I attempt to import positions
>>> such as:
>>>
>>> 85:46:05.14203W | 43:00:07.320715N
>>>
>>> I receive the error message:
>>>
>>> ERROR: x column is not of number type
>>>
>>> Is there a way to have the program recognize lat./long as legitimate
>>> entries?
>>>
>>
>> Ian:
>>
>>> Dave (or anyone else),
>>> I was wondering if you ever found out how to import lat-long data 
>>> into
>>> grass? I would like to do the same thing.
>>>
>>
>>
>> As it stands only numerical data can be used for x,y columns.
>>
>> It should be possible to change it to try G_scan_easting() and
>> G_scan_northing() if a coordinate column is of type string, but it
>> hasn't been done yet.
>>
>> You'll have to format the data as +/- DDD.DDDDDDD for now.
>>
>>
>> Hamish
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2392 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20050724/9d84f26a/attachment.bin