[GRASS-user] trouble with dbf under WINGRASS

Dear all,

last week we had a workshop about WINGRASS (grass 6.3 CR$) and Q-
GIS (0.9.1) with students who use satellite images for their theses.
We used 20 computers all with the same software WINGRASS (grass
6.3 CR$), MSYS, TCL 8.4, and Q-GIS (0.9.1). We encountered the following
problems with the dbf files:
On 2 out of 20 computers no dbf file was written when we imported
shape files into GRASS.
We were not able to use v.to.db to cvalculate areas of polygons.
The commands to add or remove columns did not work.
When we intersected vector layers about 4 out of 20 computers did
not wirte a new dbf file for the intersection result.

One computer did not remove or alter masks. The GRASS shell under
Q-GIS did not recognize the command r.mask.

All other things went very well.

Regards

Niels

-----------------------------------------
Dr. Niels Thevs
Institute of Botany and Landscape Ecology
Greifswald University
Grimmer Str. 88
17487 Greifswald
Tel.: +49-3834-86-4137
Fax: +49-3834-86-4114

===================================================================
WEB-Mailer der Uni-Greifswald ( http://www.uni-greifswald.de/ )

On 15/02/08 22:05, Niels Thevs wrote:

Dear all,

last week we had a workshop about WINGRASS (grass 6.3 CR$) and Q-
GIS (0.9.1) with students who use satellite images for their theses.
We used 20 computers all with the same software WINGRASS (grass 6.3 CR$), MSYS, TCL 8.4, and Q-GIS (0.9.1). We encountered the following problems with the dbf files:

Thanks for the feedback. What does 6.3 CR$ mean ?

On 2 out of 20 computers no dbf file was written when we imported shape files into GRASS.
We were not able to use v.to.db to cvalculate areas of polygons.
The commands to add or remove columns did not work.
When we intersected vector layers about 4 out of 20 computers did not wirte a new dbf file for the intersection result.

This sounds like a problem with the dbf driver which should be corrected in the RC4 release.
Are you sure all computers are using the same software ? Are there any other differences between computers (OS ?).

Moritz

Oh sorry, I meant GRASS 6.3. RC4, dating from Jan 15th 2008. Two more thing appeared: r.to.vect did not produce a dbf file. When I wrote a script as txt file with r.mask, there was an error message: r.mask command not found. This happened under Q-GIS with the GRASS shell as well as in GRASS.

Best regards

Niels

Moritz Lennert schrieb:

On 15/02/08 22:05, Niels Thevs wrote:

Dear all,

last week we had a workshop about WINGRASS (grass 6.3 CR$) and Q-
GIS (0.9.1) with students who use satellite images for their theses.
We used 20 computers all with the same software WINGRASS (grass 6.3 CR$), MSYS, TCL 8.4, and Q-GIS (0.9.1). We encountered the following problems with the dbf files:

Thanks for the feedback. What does 6.3 CR$ mean ?

On 2 out of 20 computers no dbf file was written when we imported shape files into GRASS.
We were not able to use v.to.db to cvalculate areas of polygons.
The commands to add or remove columns did not work.
When we intersected vector layers about 4 out of 20 computers did not wirte a new dbf file for the intersection result.

This sounds like a problem with the dbf driver which should be corrected in the RC4 release.
Are you sure all computers are using the same software ? Are there any other differences between computers (OS ?).

Moritz

--

-----------------------------------------------------
Dr. Niels Thevs
Chair of Geobotany and Landscape Ecology
Institute of Botany and Landscape Ecology
Greifswald University
Grimmer Strasse 88
17487 Greifswald
Germany

Tel.: +49-3834-86-4137
Fax: +49-3834-86-4114

-----------------------------------------------------

Niels Thevs wrote:

Oh sorry, I meant GRASS 6.3. RC4, dating from Jan 15th 2008. Two more
thing appeared: r.to.vect did not produce a dbf file. When I wrote a
script as txt file with r.mask, there was an error message: r.mask
command not found. This happened under Q-GIS with the GRASS shell as
well as in GRASS.

I am not sure, but r.to.vect may only create a DB file if one is
needed. If the attributes are just x,y(,z) and a category number there
is no need for a DB and so none may be written.
Or did r.to.vect fail with an error?

FWIW r.mask is a UNIX shell script. Are other script modules like
r.shaded.relief there & working?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Trying to respond to all your different points (only for wingrass, I
cannot say anything about QGIS).

In general, please be more precise in the description of the issues (e.g.
don't say "We were not able to use v.to.db to cvalculate areas of
polygons", but give the exact v.to.db command line you use and possibly
the data you tried this on - ideally you should use the spearfish or new
North Caroline demo data sets).

On Mon, February 18, 2008 13:15, Niels Thevs wrote:

Oh sorry, I meant GRASS 6.3. RC4, dating from Jan 15th 2008. Two more
thing appeared: r.to.vect did not produce a dbf file.

I cannot reproduce this, so you will have to give more information.

When I wrote a
script as txt file with r.mask, there was an error message: r.mask
command not found. This happened under Q-GIS with the GRASS shell as
well as in GRASS.

As Hamish has already mentioned r.mask is a shell script and so are
v.db.addcol and v.db.dropcol. So in order to be able to use them you have
to have msys installed and the grass63.bat file configured to reflect this
(see the README).

On 2 out of 20 computers no dbf file was written when we imported
shape files into GRASS.

Again: are all the machines identical (OS ?) Maybe some disk space / quota
problem ?

We were not able to use v.to.db to cvalculate areas of polygons.

As mentioned above, please be more precise on what does not work.

When we intersected vector layers about 4 out of 20 computers did not
wirte a new dbf file for the intersection result.

Which command did you use ? Again, unless the 4 computers are different
from the others, I would rather suspect some problems with disk space or
manipulation errors. Do the same problems always appear on the same
computers ?

Moritz