[GRASSLIST:2940] invalid #dims or fields for site import

Hello,
I have been trying to import sites for San Diego,
California (lat:32.861638 lon: -117.213281). Some
sites work, all the -116 sites will not (i.e.
-116.656290 32.789870). When I import the manager is
giving me this message:

ERROR: ebuf -116.656290 32.789870 nbuf @u B)
ERROR: G_site_new_struct: invalid # dims or fields

I have gone back and create multiple locations,
changed the values from decimal degree to lat/long and
still I get a message that this is an invalid #dims or
fields. Yet, I believe the -116 is within the -117
lon mark as in the lat mark..

Any suggestions?
Thanks
Stef

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

I have been trying to import sites for San Diego,
California (lat:32.861638 lon: -117.213281). Some
sites work, all the -116 sites will not (i.e.
-116.656290 32.789870). When I import the manager is
giving me this message:

ERROR: ebuf -116.656290 32.789870 nbuf @u B)
ERROR: G_site_new_struct: invalid # dims or fields

...

Any suggestions?

I take it you are using s.in.ascii,

It looks like both long and lat are being scanned as easting (ebuf), and
northing (nbuf) is being saved as garbage "@u B)".

Possible causes: the space isn't really an ASCII space, try saving as a
comma separated .csv file instead. Same for the "-", are you sure it
isn't some other font's special character that just looks like an ASCII
dash?

=> Another thing to check is that you are importing three columns of
data, even if the third column is just a bunch of "1"s or something it
has to be there. See the (updated) online version of the s.in.ascii help
page for more info.

s.in.ascii is long overdue for some hardening, to deal with both the
three column requirement and the differing DOS/UNIX newline problems[*].

[*] try the venerable "dos2unix" as well to convert DOS text files to
UNIX newline format.

Hamish

Thank you for your reply.. but this solutions does not
appear to fix the problem.

I am using s.in.dbf sites=horse input=horse The file
I am including has one field: -116.656290 32.789870
horse

This is my error:
ERROR: ebuf -116.656290 nbuf 32.789870 @"Horse"

I have used s.in.dbf on another file, but the file did
not have any negative numbers.

Any suggestions? Is there another way to force this
site into the map? Is it possible that my location
definitions are affecting this?

Thanks,
Stef

--- Hamish <hamish_nospam@yahoo.com> wrote:

> I have been trying to import sites for San Diego,
> California (lat:32.861638 lon: -117.213281). Some
> sites work, all the -116 sites will not (i.e.
> -116.656290 32.789870). When I import the manager
is
> giving me this message:
>
> ERROR: ebuf -116.656290 32.789870 nbuf @u B)
> ERROR: G_site_new_struct: invalid # dims or fields
...
> Any suggestions?

I take it you are using s.in.ascii,

It looks like both long and lat are being scanned as
easting (ebuf), and
northing (nbuf) is being saved as garbage "@u B)".

Possible causes: the space isn't really an ASCII
space, try saving as a
comma separated .csv file instead. Same for the "-",
are you sure it
isn't some other font's special character that just
looks like an ASCII
dash?

=> Another thing to check is that you are importing
three columns of
data, even if the third column is just a bunch of
"1"s or something it
has to be there. See the (updated) online version of
the s.in.ascii help
page for more info.

s.in.ascii is long overdue for some hardening, to
deal with both the
three column requirement and the differing DOS/UNIX
newline problems[*].

[*] try the venerable "dos2unix" as well to convert
DOS text files to
UNIX newline format.

Hamish

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Thank you for your reply.. but this solutions does not
appear to fix the problem.

I am using s.in.dbf sites=horse input=horse The file
I am including has one field: -116.656290 32.789870
horse

This is my error:
ERROR: ebuf -116.656290 nbuf 32.789870 @"Horse"

I have used s.in.dbf on another file, but the file did
not have any negative numbers.

Any suggestions? Is there another way to force this
site into the map? Is it possible that my location
definitions are affecting this?

could you send me the file (or a subset) to try?
[Yahoo gets grumpy if the attachment is too big.. if it bounces, let me
know and we can make other arangements]

You may be able to do something on the command line with something like:
'dbview -b <filename.dbf> | cut -d":" -f1,2,3,4 | s.in.ascii'

I seem to remeber there were some fixes to s.in.dbf by Thierry Laronde
that never got applied (mostly because GRASS 5.7 will read in DBF files
directly so it is a non-issue for future development) but should be.

see
http://article.gmane.org/gmane.comp.gis.grass.devel/2517
http://article.gmane.org/gmane.comp.gis.grass.devel/2522

fixes:
http://freegis.org/cgi-bin/viewcvs.cgi/grass/src.garden/grass.postgresql/pg.in.dbf/

Hamish