[GRASS-dev] GRASS and QGIS on Win32, testing etc.
benjamin.ducke at ufg.uni-kiel.de
Mon May 21 13:58:12 CEST 2007
as some of you will know, I am keen on pushing GRASS as the GIS of
choice for serious data analysis in my discipline, which is archaeology.
To this end, I have written a number of specific extension, that are of
special value for archaeologists, but may also be applied to other
fields (e.g. predictive modelling).
My colleagues are pretty tired with high prices and lacking
functionality in commercial GIS and if GRASS can be established now, the
potential future benefits for the software and the scientific community
are great. The time is ripe now to claim this field for GRASS!
I can tell you that interest in GRASS (and QGIS) is enormous among
archaeologists, but it will not be possible to establish GRASS unless
there is a version that installs and runs well on Win32.
Now, I have been following the diverse attempts to migrate GRASS to
Win32 -- CygWin, cross compiling, MSYS, etc. -- but I am finally getting
totally confused about where things are heading.
So far, I get the most usable system using the MSYS building environment
provided by the QGIS developers.
HOWEVER, there are two issues that have been sticking around for months
now and prevent me from using the software productively in GIS classes:
1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.
Is this the same bug that was/is being discussed under "What is missing"
here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status ???
I have replaced the QGIS 0.8.1 rc1 GRASS binaries with Moritz' version,
but the problem persists. If you want to verify this, here is the sample
location I used:
... very simple point data, projection free.
2. There are still issues when QGIS is installed in a path with spaces.
This is a problem with the GRASS modules. I found that at least
g.mremove and d.mon screwed up. There are probably others ...
My problem simply is that I am getting tangled up in the different Win32
migration schemes used by the GRASS and QGIS developers. I would love to
provide Win32 testing feedback and reports for compilation, installation
and usage, but I simply don't know where to start!
Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams? As far
as I understand, Moritz' system differs in that it supports the Tcl/Tk
stuff? But now there is talk about getting rid of MSYS?
Sorry for the lengthy post and all the complaining but if you could
stand inside my shoes right now, you would see a great chance to claim a
good share of an entire discipline for GRASS GIS. And not being able to
make use of this is pretty frustrating.
Paul Kelly wrote:
> On Mon, 21 May 2007, Moritz Lennert wrote:
>> I just noticed that the path to the msys shell was not correctly defined,
>> and that was why they did not execute...duh.
> Ah yes you also need the GRASS_SH environment variable set properly,
> which I forgot to mention. It should contain the path to the shell
> interpreter in Windows path syntax, and is used both by the .bat script
> launch mechanism and by g.parser when it "re-launches" each script after
> processing the parser options. For that reason it is also used when
> WinGRASS is started from Init.sh and it is set both in Init.sh and
> init.bat, but if you set it before running them then it won't overridden.
>>> Actually though you need to make sure you have the Msys bin and
>>> MinGW bin and lib directories in your PATH, maybe that's it? That's
>>> something else I've glossed over and should have mentioned, sorry.
>>> Need to
>>> look into that further (Msys documentation perhaps???)
>> Setting the path variable works great. I now get scripts to actually
>> using msys' shell tools ! I'll add this to the README of the wingrass
> Good to hear. Note it's generally a bad idea (for troubleshooting and
> developing) to always have the Msys/MinGW directories in your path as
> then you miss some Unixisms in the code such as system("ls") which will
> work fine if you have a version of ls in your path.
>>> : I'd originally
>>> hoped that if you started the Msys shell it would insert its needed
>>> directories into the PATH automatically, but that doesn't seem to happen
>>> and I never got round to extending the .bat script-launching system
>>> to do
>>> any path manipulation because, to do that elegantly we need to look at
>>> documentation for other Windows ports of bourne shell interpreters
>>> and see
>>> how they handle being launched in this way, specifically path-related
>> Although I agree that we should try to aim for as general as possible,
>> shouldn't we start by getting winGRASS working nicely with msys as a
>> requirement and then slowly work away from that ? Or do you fear that
>> will make us too lazy and not solve the real issues from the start ?
> Exactly. Have seen that happening loads of times before and thought I'd
> avoid it and leave it until we can do things in a more general way! I
> hate "half-fixing" solutions as it often requires more work later on to
> undo the half-fix before putting in the "full fix", resulting in user
> inconvenience that something which used to work now doesn't or has to be
> done in a different way etc...
> grass-dev mailing list
> grass-dev at grass.itc.it
Benjamin Ducke, M.A.
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
D 24098 Kiel
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
More information about the grass-dev