[GRASS-dev] select issue with wingrass

I have a postdoc who just arrived to learn a bit of GRASS in my lab today. He installed WinGRASS about a week ago. It launches fine. But he cannot see any of the map files inside the mapset when he tries to add a map to a GUI window. This is controlled by select.tcl. We checked this against the Spearfish dataset and confirmed that the data are fine and that he does have access to the maps. In fact, if he types in a map name, any module seems to run fine–including displaying a map in the GIS Manager.

When you click a button to launch select.tcl, you get a window/dialog with a tree which shows available mapsets and, if they exist, any accessible maps in the mapset. You can select a map and click OK. Everything works for Javi except seeing the maps inside the mapsets. He can even see the mapsets (first level of the tree); just not the maps inside a mapset.

A first guess on my part is something to do with translating forward slash for *nix and Mac “/” to backward slash for Windows "". The odd thing is that this worked fine with earlier builds of WinGRASS, so maybe it’s something else.

Have either of you guys run into this?

Thanks
Michael


Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

I have a postdoc who just arrived to learn a bit of GRASS in my lab today.
He installed WinGRASS about a week ago. It launches fine. But he cannot see
any of the map files inside the mapset when he tries to add a map to a GUI
window. This is controlled by select.tcl. We checked this against the
Spearfish dataset and confirmed that the data are fine and that he does have
access to the maps. In fact, if he types in a map name, any module seems to
run fine--including displaying a map in the GIS Manager.

When you click a button to launch select.tcl, you get a window/dialog with a
tree which shows available mapsets and, if they exist, any accessible maps
in the mapset. You can select a map and click OK. Everything works for Javi
except seeing the maps inside the mapsets. He can even see the mapsets
(first level of the tree); just not the maps inside a mapset.

A first guess on my part is something to do with translating forward slash
for *nix and Mac "/" to backward slash for Windows "\". The odd thing is
that this worked fine with earlier builds of WinGRASS, so maybe it's
something else.

The relevant code is:

    # main selection subroutine
    if {$element != "symbol"} {
        foreach dir [exec g.mapsets -p] {
            set windfile "$location_path/$dir/WIND"
            if { ! [ file exists $windfile ] } { continue }
            if { $dir == $current_mapset } {
                $tree insert end root ms_$dir -text $dir -data $dir -open 1 \
                -image [Bitmap::get openfold] -drawcross auto
            } else {
                $tree insert end root ms_$dir -text $dir -data $dir -open 0 \
                -image [Bitmap::get folder] -drawcross auto
            }
            set path "$location_path/$dir/$element/"
            foreach fp [ lsort [glob -nocomplain $path/*] ] {
            set file [file tail $fp]
            $tree insert end ms_$dir $file@$dir -text $file -data $file \
                -image [Bitmap::get file] -drawcross never
            }
        }
    }

The "file exists $windfile" test is obviously working, otherwise he
wouldn't see the mapsets. The most likely problem is with the "glob"
command. The glob(n) manpage implies that / should work. Can you try
running tclsh/wish interactively and testing the behaviour of the glob
command?

--
Glynn Clements <glynn@gclements.plus.com>

On 06/11/07 03:16, Michael Barton wrote:

I have a postdoc who just arrived to learn a bit of GRASS in my lab today. He installed WinGRASS about a week ago. It launches fine. But he cannot see any of the map files inside the mapset when he tries to add a map to a GUI window. This is controlled by select.tcl. We checked this against the Spearfish dataset and confirmed that the data are fine and that he does have access to the maps. In fact, if he types in a map name, any module seems to run fine--including displaying a map in the GIS Manager.

When you click a button to launch select.tcl, you get a window/dialog with a tree which shows available mapsets and, if they exist, any accessible maps in the mapset. You can select a map and click OK. Everything works for Javi except seeing the maps inside the mapsets. He can even see the mapsets (first level of the tree); just not the maps inside a mapset.

A first guess on my part is something to do with translating forward slash for *nix and Mac "/" to backward slash for Windows "\". The odd thing is that this worked fine with earlier builds of WinGRASS, so maybe it's something else.

Have either of you guys run into this?

No, I've never had that problem. I'll test, but won't be in front of a win machine before tomorrow.

Moritz

Glynn,

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Michael

On 11/6/07 2:55 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

The relevant code is:

    # main selection subroutine
    if {$element != "symbol"} {
        foreach dir [exec g.mapsets -p] {
            set windfile "$location_path/$dir/WIND"
            if { ! [ file exists $windfile ] } { continue }
            if { $dir == $current_mapset } {
                $tree insert end root ms_$dir -text $dir -data $dir -open 1 \
                -image [Bitmap::get openfold] -drawcross auto
            } else {
                $tree insert end root ms_$dir -text $dir -data $dir -open 0 \
                -image [Bitmap::get folder] -drawcross auto
            }
            set path "$location_path/$dir/$element/"
            foreach fp [ lsort [glob -nocomplain $path/*] ] {
            set file [file tail $fp]
            $tree insert end ms_$dir $file@$dir -text $file -data $file \
                -image [Bitmap::get file] -drawcross never
            }
        }
    }

The "file exists $windfile" test is obviously working, otherwise he
wouldn't see the mapsets. The most likely problem is with the "glob"
command. The glob(n) manpage implies that / should work. Can you try
running tclsh/wish interactively and testing the behaviour of the glob
command?

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Run tclsh in a console, and type e.g.:

  glob -nocomplain C:/*

--
Glynn Clements <glynn@gclements.plus.com>

On 06/11/07 16:12, Moritz Lennert wrote:

On 06/11/07 03:16, Michael Barton wrote:

I have a postdoc who just arrived to learn a bit of GRASS in my lab today. He installed WinGRASS about a week ago. It launches fine. But he cannot see any of the map files inside the mapset when he tries to add a map to a GUI window. This is controlled by select.tcl. We checked this against the Spearfish dataset and confirmed that the data are fine and that he does have access to the maps. In fact, if he types in a map name, any module seems to run fine--including displaying a map in the GIS Manager.

When you click a button to launch select.tcl, you get a window/dialog with a tree which shows available mapsets and, if they exist, any accessible maps in the mapset. You can select a map and click OK. Everything works for Javi except seeing the maps inside the mapsets. He can even see the mapsets (first level of the tree); just not the maps inside a mapset.

A first guess on my part is something to do with translating forward slash for *nix and Mac "/" to backward slash for Windows "\". The odd thing is that this worked fine with earlier builds of WinGRASS, so maybe it's something else.

Have either of you guys run into this?

No, I've never had that problem. I'll test, but won't be in front of a win machine before tomorrow.

Just tested and I cannot confirm this problem with any of the currently available versions (6.3RC1, cvs of of Nov. 1, current cvs). So, it seems to me that this is a specific issue in Ravi's installation. Where is his GISDBASE ? Is it on his machine or is it a networked drive ? Have you tried this with the spearfish data ?

Moritz

Glynn, Moritz, and Benjamin,

Tried this and it worked fine. Downloaded and installed the current (2
November) binary and still have the same problem.

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice).

If there is a problem with Javier's installation, what do we need to do to
completely clean it off and try again? (maybe keep TclTk since it seems to
be OK?).

Michael

On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Run tclsh in a console, and type e.g.:

glob -nocomplain C:/*

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

Glynn, Moritz, and Benjamin,

Tried this and it worked fine. Downloaded and installed the current (2
November) binary and still have the same problem.

To re-iterate Moritz's line of thought: were is the data stored? Are you
accessing it over the network? Could there be a permissions problem with
Javier's user account? Is he allowed to look into the folders for the
mapsets?

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice).

Some troubles with the DBF driver on Win have been reported on the QGIS
mailing list as well, but this seems to be a separate issue. What
exactly is the error message?

If there is a problem with Javier's installation, what do we need to do to
completely clean it off and try again? (maybe keep TclTk since it seems to
be OK?).

WinGRASS does no tinker with any system files. Simply delete the whole
installation folder and you are rid of it.

Benjamin

Michael

On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Run tclsh in a console, and type e.g.:

glob -nocomplain C:/*

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Hi Benjamin,

On 11/9/07 3:34 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:

Michael Barton wrote:

Glynn, Moritz, and Benjamin,

Tried this and it worked fine. Downloaded and installed the current (2
November) binary and still have the same problem.

To re-iterate Moritz's line of thought: were is the data stored? Are you
accessing it over the network? Could there be a permissions problem with
Javier's user account? Is he allowed to look into the folders for the
mapsets?

Sorry. Forgot to mention. All are in C:/grassdata. We've checked permissions
and even copied files locally to make sure of ownership. There no problem
USING the maps as long as we type their names into the GUI entry boxes.
There is simply the problem of SEEING the maps in the TclTk directory
listing.

I simply have no idea where this problem is localized. If someone can
install the new binaries from scratch and test it would be helpful (I'll try
to find someone here to do that too).

I don't know whether it is a particular problem with Javi's machine or a
general problem that binary maintainers can't see because you've installed a
lot of stuff to compile GRASS.

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice).

Some troubles with the DBF driver on Win have been reported on the QGIS
mailing list as well, but this seems to be a separate issue. What
exactly is the error message?

Javi will email me this and I'll forward it on. When we look at details, it
claims a problem with a dll (don't remember which one).

Also getting an error on gdal import complainging about a gcs.cvs file

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

=====

But we have a LOT of these and they seem to be in the right places.

=====

gcs grass/share/gdal
gcs grass/grass-6.3.csv/etc/ogr_csv
gcs C:\Program Files\Quantum GIS
gcs C:\Program Files\Data Interoperability Extensions\Reproject\epsg

=====

If there is a problem with Javier's installation, what do we need to do to
completely clean it off and try again? (maybe keep TclTk since it seems to
be OK?).

WinGRASS does no tinker with any system files. Simply delete the whole
installation folder and you are rid of it.

Thanks!

Michael

Benjamin

Michael

On 11/6/07 8:53 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

I agree that it certainly looks like the problem code is

glob -nocomplain $path/*

"glob" ought to work because it is pure TclTk in this case (although
identical to the unix command). What about the "*"?

I don't know how to test this on Windows. Suggestions?

Run tclsh in a console, and type e.g.:

glob -nocomplain C:/*

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On 09/11/07 15:32, Michael Barton wrote:

Hi Benjamin,

On 11/9/07 3:34 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:

Michael Barton wrote:

Glynn, Moritz, and Benjamin,

Tried this and it worked fine. Downloaded and installed the current (2
November) binary and still have the same problem.

To re-iterate Moritz's line of thought: were is the data stored? Are you
accessing it over the network? Could there be a permissions problem with
Javier's user account? Is he allowed to look into the folders for the
mapsets?

Sorry. Forgot to mention. All are in C:/grassdata. We've checked permissions
and even copied files locally to make sure of ownership. There no problem
USING the maps as long as we type their names into the GUI entry boxes.
There is simply the problem of SEEING the maps in the TclTk directory
listing.

Could you also tell us which version of windows this is ?

I simply have no idea where this problem is localized. If someone can
install the new binaries from scratch and test it would be helpful (I'll try
to find someone here to do that too).

I'll try that as soon as I have the time, but that won't be before next Wednesday or Thursday.

I don't know whether it is a particular problem with Javi's machine or a
general problem that binary maintainers can't see because you've installed a
lot of stuff to compile GRASS.

One of our students has been testing wingrass and hasn't reported this issue.

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice).

Some troubles with the DBF driver on Win have been reported on the QGIS
mailing list as well, but this seems to be a separate issue. What
exactly is the error message?

Javi will email me this and I'll forward it on. When we look at details, it
claims a problem with a dll (don't remember which one).

The problems reported with the dbf driver recently are due to some bug in the driver which keep inserts and updates from working. But I have not had any reports about a dll issue.

How are you creating the points ?

Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

Have you tried setting this ?

Just to be sure: could you tell us how exactly Javi launches wingrass and what is the content of his grass63.bat file ?

Moritz

Hi Moritz,

See some answers below. I'm copying Javi so that he can respond directly
too.

On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 15:32, Michael Barton wrote:

Could you also tell us which version of windows this is ?

Windows XP (I don't know if there is a specific version number or not. I can
ask him in the lab later this morning). It is an English-language version of
XP, so there are not undetected issues with languages and translations.

I simply have no idea where this problem is localized. If someone can
install the new binaries from scratch and test it would be helpful (I'll try
to find someone here to do that too).

I'll try that as soon as I have the time, but that won't be before next
Wednesday or Thursday.

Thanks.

I don't know whether it is a particular problem with Javi's machine or a
general problem that binary maintainers can't see because you've installed a
lot of stuff to compile GRASS.

One of our students has been testing wingrass and hasn't reported this
issue.

This is a help. I'm going to try to get a student in my lab to try it too.

Now were are constantly getting an error with dbf.ext when we are trying to
create points from a DBF table (only 6 points). The table is fine (checked
in OpenOffice).

Some troubles with the DBF driver on Win have been reported on the QGIS
mailing list as well, but this seems to be a separate issue. What
exactly is the error message?

Javi will email me this and I'll forward it on. When we look at details, it
claims a problem with a dll (don't remember which one).

The problems reported with the dbf driver recently are due to some bug
in the driver which keep inserts and updates from working. But I have
not had any reports about a dll issue.

How are you creating the points ?

v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
Excel issues). It certainly looks perfectly good.

Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

Have you tried setting this ?

How would we go about setting this?

Just to be sure: could you tell us how exactly Javi launches wingrass
and what is the content of his grass63.bat file

He launches it from a shortcut on the desktop to the grass63.bat file (I
don't know where the original is, but will ask him). I can ask him to send
you his bat file too. I think he got it from your site.

Thanks for all the help.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On 09/11/07 18:41, Javier Fernandez wrote:

Hi all, I have attached a word file with the problems that I find when I work with wingrass,

Thank you. Could you give the precise commands/actions you take to see these errors ?

e.g.:

Problem 2: Unable to create points from a dbf. File: because a dbf error

Output GIS

NG: GRASS_TRUECOLOR status: TRUE

PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,

     GRASS_WIDTH=575, GRASS_HEIGHT=484

Unable to open vector map <Yaci@PERMANENT> on topology level 0

and then you show a screenshot of the windows error message. But what do you do to get this result ? The above error message ("Unable to open...") seems to be related to displaying a map, whereas you say it is linked to v.to.db ?

Problem 2: Unable to import a shapefile using OGR

What is the exact command you use to import it ?

And for

1. Is not possible select in the Select Item window’s.

Could you try to see if you have the same problem with the spearfish60 demo location ?

Moritz

On 09/11/07 16:25, Michael Barton wrote:

Hi Moritz,

See some answers below. I'm copying Javi so that he can respond directly
too.

On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 15:32, Michael Barton wrote:

Could you also tell us which version of windows this is ?

Windows XP (I don't know if there is a specific version number or not. I can
ask him in the lab later this morning).

I don't think this is necessary.

I don't know whether it is a particular problem with Javi's machine or a
general problem that binary maintainers can't see because you've installed a
lot of stuff to compile GRASS.

One of our students has been testing wingrass and hasn't reported this
issue.

This is a help. I'm going to try to get a student in my lab to try it too.

Please also try it with the spearfish demo location.

How are you creating the points ?

v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
Excel issues). It certainly looks perfectly good.

It is quite probable that this will probably not work because of the current bug in the dbf driver. Although AFAICT this should not cause a windows dll error...

Could you try creating an sqlite table with the same data and use v.in.db on that ?
You have to make sure that the sqlite executable (and I think library) are in your path.
You can set the PATH in the grass63.bat file:
set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib

Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

Have you tried setting this ?

How would we go about setting this?

Try setting it in the grass63.bat file:

set GDAL_DATA=

But is this a GRASS variable or a GDAL variable ?

Moritz

On 11/9/07 11:04 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 16:25, Michael Barton wrote:

This is a help. I'm going to try to get a student in my lab to try it too.

Please also try it with the spearfish demo location.

Did this.

How are you creating the points ?

v.in.db. We are using a dbf file that we've created in OpenOffice (to avoid
Excel issues). It certainly looks perfectly good.

It is quite probable that this will probably not work because of the
current bug in the dbf driver. Although AFAICT this should not cause a
windows dll error...

Could you try creating an sqlite table with the same data and use
v.in.db on that ?
You have to make sure that the sqlite executable (and I think library)
are in your path.
You can set the PATH in the grass63.bat file:
set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib

Can do that. But the issue is simply trying create points from a DBF. This
is important for my teaching next semester too. Insisting that students try
to figure out SQLite isn't very feasible.

I thought that the dbf error was fixed. If not, it is good to know that
v.in.db doesn't work currently. We can just use v.in.ascii instead.

Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

Got this dealt with. Interestingly, trying to import a file with an
incorrect format with v.in.ascii gives the same error as trying to import a
dbf file with v.in db, using dbf format. I don't know if this helps debug,
but maybe it is a clue.

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

Have you tried setting this ?

How would we go about setting this?

Try setting it in the grass63.bat file:

set GDAL_DATA=

You mean leave this blank/empty? Or do you mean to point this variable to a
valid location?

But is this a GRASS variable or a GDAL variable ?

I have absolutely no idea.

Moritz

Thanks for the help.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On 11/9/07 10:59 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 18:41, Javier Fernandez wrote:

Hi all, I have attached a word file with the problems that I find when I
work with wingrass,

Thank you. Could you give the precise commands/actions you take to see
these errors ?

e.g.:

Problem 2: Unable to create points from a dbf. File: because a dbf error

Output GIS

NG: GRASS_TRUECOLOR status: TRUE

PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,

     GRASS_WIDTH=575, GRASS_HEIGHT=484

Unable to open vector map <Yaci@PERMANENT> on topology level 0

and then you show a screenshot of the windows error message. But what do
you do to get this result ? The above error message ("Unable to
open...") seems to be related to displaying a map, whereas you say it is
linked to v.to.db ?

The screenshot is an error caused by v.in.db.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On 09/11/07 19:19, Michael Barton wrote:

On 11/9/07 11:04 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Could you try creating an sqlite table with the same data and use
v.in.db on that ?
You have to make sure that the sqlite executable (and I think library)
are in your path.
You can set the PATH in the grass63.bat file:
set PATH=%PATH%;PathToSqliteBin;PathToSqliteLib

Can do that. But the issue is simply trying create points from a DBF. This
is important for my teaching next semester too. Insisting that students try
to figure out SQLite isn't very feasible.

The idea is not to tell you to use sqlite from now on, just to test whether the problem really is with the dbf driver or whether it is something else. Trying it with a different database backend helps narrowing down the issue.

Could you also send me the dbf so that I can try ?

I thought that the dbf error was fixed. If not, it is good to know that
v.in.db doesn't work currently. We can just use v.in.ascii instead.

Glynn rewrote a section of the dbmi library, i.e. the one treating all database interaction (not only dbf), but recently a new bug was discovered and I have been able to narrow it down to the dbf driver, but not have had more time to work on it since. However, this did not involve a windows error message such as you have...

Also getting an error on gdal import complainging about a gcs.cvs file

Haven't used gdal import for a while in wingrass, so will test that.

Got this dealt with. Interestingly, trying to import a file with an
incorrect format with v.in.ascii gives the same error as trying to import a
dbf file with v.in db, using dbf format. I don't know if this helps debug,
but maybe it is a clue.

Quite probably. What is the incorrect format ?

=====

ERROR 4: Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the
directory containing EPSG csv files.

Have you tried setting this ?

How would we go about setting this?

Try setting it in the grass63.bat file:

set GDAL_DATA=

You mean leave this blank/empty? Or do you mean to point this variable to a
valid location?

The latter.

But is this a GRASS variable or a GDAL variable ?

I have absolutely no idea.

This questions was directed more to Glynn than to you :wink:

Moritz

On 09/11/07 19:27, Michael Barton wrote:

On 11/9/07 10:59 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 18:41, Javier Fernandez wrote:

Hi all, I have attached a word file with the problems that I find when I
work with wingrass,

Thank you. Could you give the precise commands/actions you take to see
these errors ?

e.g.:

Problem 2: Unable to create points from a dbf. File: because a dbf error

Output GIS

NG: GRASS_TRUECOLOR status: TRUE

PNG: collecting to file: C:\grassdata/Spain_utm_30n/PERMANENT/.tmp/928.0.ppm,

     GRASS_WIDTH=575, GRASS_HEIGHT=484

Unable to open vector map <Yaci@PERMANENT> on topology level 0

and then you show a screenshot of the windows error message. But what do
you do to get this result ? The above error message ("Unable to
open...") seems to be related to displaying a map, whereas you say it is
linked to v.to.db ?

The screenshot is an error caused by v.in.db.

Could you send the content of the 'technical information' (link in the error window) of the error reports ? I'm not sure I'll understand these (MS does not have the reputation of creating useful error messages...), but it's worth a try.

Moritz

On 09/11/07 19:04, Moritz Lennert wrote:

On 09/11/07 16:25, Michael Barton wrote:

Hi Moritz,

See some answers below. I'm copying Javi so that he can respond directly
too.

On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 15:32, Michael Barton wrote:

Could you also tell us which version of windows this is ?

Windows XP (I don't know if there is a specific version number or not. I can
ask him in the lab later this morning).

I don't think this is necessary.

Correcting myself: maybe it actually is as I imagine that there could be a conflict between different versions of msvcrt.dll

Moritz

>>>> ERROR 4: Unable to open EPSG support file gcs.csv.
>>>> Try setting the GDAL_DATA environment variable to point to the
>>>> directory containing EPSG csv files.
>>> Have you tried setting this ?

..

> Try setting it in the grass63.bat file:
>
> set GDAL_DATA=

You mean leave this blank/empty? Or do you mean to point this variable to a
valid location?

point it to the relevant C:\... path

> But is this a GRASS variable or a GDAL variable ?

I have absolutely no idea.

it is an enviroment variable used by GDAL.

Hamish

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Moritz,

At least some of this was solved this afternoon by my very enterprising RA.
It turns out that Javi was following the installation directions too
closely.

He simply opened the zip file (in WinZip I think), and dragged the grass
folder onto his C: drive.

This won't produce a complete working GRASS (though very confusing, it will
produce an ALMOST working GRASS).

Isaac, had Javi reinstall by expanding EVERYTHING in the zip file into C:.
Apparently, there are some hidden files that also need to get onto the C:
drive, and that don't get there by just dragging the grass folder from zip
file.

Ultimately, the most reliable thing, I guess, would be to create a
self-extracting archive (*.exe). But maybe you understand what when wrong (I
still don't know what is missing with the other installation method).

Still haven't tested everything, but the file selection and some other
things work now (as of 3pm when I had to leave the lab). Hope to find out if
v.in.db works too.

Thanks for working with us on this.

Michael

On 11/9/07 11:53 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 09/11/07 19:04, Moritz Lennert wrote:

On 09/11/07 16:25, Michael Barton wrote:

Hi Moritz,

See some answers below. I'm copying Javi so that he can respond directly
too.

On 11/9/07 8:01 AM, "Moritz Lennert" <mlennert@club.worldonline.be>
wrote:

On 09/11/07 15:32, Michael Barton wrote:

Could you also tell us which version of windows this is ?

Windows XP (I don't know if there is a specific version number or not.
I can
ask him in the lab later this morning).

I don't think this is necessary.

Correcting myself: maybe it actually is as I imagine that there could be
  a conflict between different versions of msvcrt.dll

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton