[GRASS-user] Re: [Qgis-developer] Re: [Qgis-user] QGIS & GRASS

[Benjamin Ducke]

Hi all,

I have used QGIS and the GRASS plugin extensively for GIS training in
the past. I still think that it is a great combination but has suffered
from a long period of inactive development. It is good to see that some
new life is finally being breathed into the GRASS plugin!

In the past, usability of QGIS + GRASS has been limited for me, due
to the following problems. I must admit that I have not given things
another try with one of the recent QGIS versions, so some of these
issues might have been addressed already:

1. QGIS flattens 3D vector layers to 2D. While GRASS is one of the few
GIS that have some real 3D power, it's hard to harness that under QGIS.
This needs fixing on the QGIS side. 3D coordinates should at least be
kept in QGIS layers, not just silently discarded.

2. There is no support at all for voxel type maps in the GRASS plugin.

3. The region setting tool is far too limited. One of the great things
about GRASS is how easy it is to set the computational region precisely
to the extent of e.g. one or several maps. But I always have to go
back to g.region on the CLI because the graphical tool is useless.
Particularly for 3D settings.

4. A better widget for multiple map input selection (e.g. r.patch) is
needed.

5. On the GRASS side, we need to come up with some sort of signaling
mechanism that allows QGIS (or any other "host") to know when the
computational region or any map data has been modified.

6. Colour schemes for raster maps and vector maps ("GRASSRGB" column
in attribute table) should be honored for display by QGIS.

My feeling is that most of these points would not be too hard to
address. With a little work on the rough edges, GRASS + QGIS could
be a beautiful, smoothly working combination.

Ben


G. Allegri wrote:
> +1
> I understand the importance and the need to give all the best to the
> core dev, as there are many parts that need to be
> mantained/updated/refactored/built (ie the raster core code in
> qgis...), but I support a boost to the 'joints' of the systems
> integration. as I think that their integration is a leading factor for
> their diffusion and presence in the end-user community.
> I'm happy to see the proposal from Paolo about a found raising for
> qgis-grass-plugin, and I hope I will be able to contribute (also
> economically).
> The other important (foundamental, in my opinion) issue is the Windows
> support. I've tried to give a help for the Osgeo4w stack some time
> ago, but I've wasted all my time in trying to solve Windows Vista's
> problems... without very good results!
> 
> have a nice day,
> giovanni
> 
> 
> 2009/5/4 Nikos Alexandris <nikos.alexandris at felis.uni-freiburg.de>:
>> On Mon, 2009-05-04 at 08:49 +0200, Paolo Cavallini wrote:
>> ---%<---
>>> I would therefore respectfully suggest devs, form the users perspective,
>>> to consider concentrating on the best of each world, reducing the
>>> duplication of efforts, and improving the (already good) interaction
>>> between the two programs.
>> ---%<---
>>
>> +1 to that from an end-user like me.
>>
>> I would like also to mention OpenEV. It is the fastest geodata viewer
>> [period]. I don't know the coding background and the differences for
>> among QGIS, GRASS and OpenEV, but why not use it, create interaction
>> with it _or_ use parts of its code _or_ just look at some of its
>> attractive features?
>>
>> Kindest regards, Nikos
>>
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 


-- 
Benjamin Ducke
Senior Geospatial Consultant

Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.