[GRASS5] s.in.dbf

Last Spring, when I was doing a lot of testing, trying to bring my archaeological research data into GRASS, I ran into a problem with s.in.dbf. Basically, it didn't work right. Sometimes it wouldn't import anything and other times it would import the site points (i.e., xy coordinates) and text fields, but remaining fields would go to 0.

Various people were helpful and the problems were finally reported as solved in the CVS. I couldn't test it at the time as I was unable to build grass for a variety of reasons.

A short time ago I was able to build version 5.3 successfully. I just tried s.in.dbf and it worked (that is didn't work) as before. It imported my test dbf file, put the points in the correct place, put all the field names correctly in the description line, then misread the actually number of numeric fields (6 instead of the proper 11) and set all values to 0.

Is this because 1) the old version rather than the fixed version somehow is included in the CVS snapshot of GRASS 5.3? or 2) because the fix (which I was never able to test before) didn't really fix the problem and no one knew that until now? Has anyone else had any problems with this? Is there a secret codeword I am missing :wink:

I'd like to tell my class here at Valencia that it works (it came up this week which prompted me to try it again).

Saludos
Michael Barton
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671

Hello Michael,

On Wed, Nov 19, 2003 at 11:10:32PM +0100, Michael Barton wrote:

Last Spring, when I was doing a lot of testing, trying to bring my
archaeological research data into GRASS, I ran into a problem with
s.in.dbf. Basically, it didn't work right. Sometimes it wouldn't import
anything and other times it would import the site points (i.e., xy
coordinates) and text fields, but remaining fields would go to 0.

I have hit some bugs with the `PostgreSQL' flavor of the DBF support.

Having a quick glance at the source, many problems lie in the file
dump.c (the `init' bug I have fixed in pg.in.dbf, no dynamic allocation
of data (leading to a buffer overflow) etc.).

As emphasize some weeks ago, there are thousands of duplicates/clones so
it's useless to fix something in some place, since the bugs will remain
elsewhere...

Solution:

May I suggest to dump in ASCII using the fixed version (in 5.O HEAD aka
5.3) of pg.in.dbf, format the file with some awk black magic, and
reimport using s.in.ascii ?

The new version of pg.in.dbf let you specify (in admin mode) the
separator, making it relatively easy to treat the result with awk or
some other fields processor.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C