[GRASS-dev] GRASS and QGIS on Win32, testing etc.

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Mon May 21 09:40:00 EDT 2007


> How is this more usable then our native builds ? Or are you speaking
> about using GRASS from within QGIS ?

Sorry, should have been more clear about this: for me the best-working
option for GRASS on Win32 is GRASS + QGIS. I successfully used this to
teach some advanced spatial analysis to GIS novices in the past and was
amazed at how smooth it went.

>> 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
>> 0% CPU.
>> 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 ???
> 
> No, this issue was solved by compiling xdr as static, instead of shared
> library. See followups on the same page.

OK. Too bad. This bug is the single remaining reason for me to delay
putting the software on our institute's pc lab. I tried to find the
cause for this, but eventually got stranded in the DBMI C code without a
good clue.

>>
>> 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 ...
> 
> d.mon ? Does that mean you get GRASS monitors working ?

No, sorry for causing a fuzz here. All I got was an error message with a
broken path. No idea if it would get any further than that, anyway; but
I thought it was worth mentioning for a future bug fix.

> 
> g.mremove is a script which can cause all kinds of shell related problems.

Yep, and we'll have to look into all of them to make sure they can use
these screwed-up Win pathnames, no?

> 
> From a pure GRASS point of view, please test the native builds I post
> regularly.

OK, so I'll stick with those.


>>
>> 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? 
> 
> I think that this might be good idea, but we have to make sure that we
> are aiming at the same things.

For me, this would be an MSYS environment where I can compile a set of
modules that will work stand-alone or with QGIS. And it looks like this
is possible already, except that the directory layout is a bit different
(everything in the grass-6.3.cvs/lib dir goes into the QGIS install dir,
according to the defaults of the QGIS package). I think what's most
important is that the people who make the QGIS-GRASS packages currently
join in to work in a single compile environment and produce a single set
of binaries.

> > 
> This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc)
> will either have to be replaced by C-versions (which kind of defeats
> their purpose of being easily codable for a larger number), be coded in
> a cross-platform scripting language (e.g. Python), or anyone who wants
> to use these under Windows has to provide access to a series of shell
> tools (e.g. through Msys).

Well, it would certainly have the positive effect of eliminating the
separate MSYS home dir that Win users have to put up with currently --
that is if all unix shell dependencies can be dropped eventually.

> 
> I am in the same situation as you are (we will migrate all our courses
> to free software starting next academic year !), so let's try to solve
> this together as quickly as possible. :-)

Great to here, so let's do it!

> 
> Moritz
> 
> 

-- 
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




More information about the grass-dev mailing list