[Qgis-developer] Re: composer redesign branch

[John C. Tull]

On Feb 13, 2008, at 2:59 AM, Tim Sutton wrote:

>> To me, geoprocessing is far less important, as this can be easily  
>> done
>> with grass.
>
> For 1.0 I agree. In the long term however I think its important to
> implement geoprocessing tools in QGIS. My typical use case for QGIS is
> using the libraries to embed GIS support into 3rd party applications -
> and increasingly others will be doing the same now that we have
> Martins python bindings in play. GRASS is problematic in this case in
> that it is a) incredibly difficult to package an application that
> makes use of some GIS functionality and then have to resolve all the
> packaging issues of bundling GRASS with it too, and b) the model of
> importing and exporting data to and from GRASS in order to perform
> analysis is onerous. There are many other reasons why I think its good
> for us to embark on implementing our own geoprocessing functionality
> (on top of GEOS etc where appropriate).
>
> Regards
>
> Tim

Just a user perspective here, but I agree with Tim 100% on his part b  
assessment. The import export model works, and I am grateful to have  
the GRASS plugin, but this process creates a lot of redundancy in data  
files between the two systems (grass/qgis) that quickly can quickly  
become unmanageable. Workflow would be greatly improved greatly with  
geoprocessing tools available in qgis. Also, I do think that better  
map printing is much higher priority than geoprocessing at this point.  
It is a bit problematic that it takes me a full day to create a map  
that approaches the visual quality that my colleague can complete in  
15 minutes using Arc/ESRI.

Thanks,
John