towards qgis 1.0 (was:Re: [Qgis-developer] Re: composer redesign branch)

John C. Tull john.tull at wildnevada.org
Wed Feb 13 12:30:35 EST 2008


On Feb 13, 2008, at 3:33 AM, Paolo Cavallini wrote:

> Tim Sutton ha scritto:
>
>> 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).
>
> I generally agree with you. Please note, however, that converting  
> vector
> data into grass format is not always necessary, thanks to  
> v.external. I
> understand next grass should be able to do the same also with raster
> (sort of r.external).
> But of course having at least some geoprocessing would be nice, just  
> do
> not stop the path towards 1.0 because of this...
> All the best.
> pc

Paolo,

I will have to investigate using v.external as this may help reduce  
the redundancy problem, although it is unclear how at this point. Are  
you referring to running v.external from the grass shell? Perhaps a  
quick example of your workflow would be good (a tutorial?).

Cheers,
John


More information about the Qgis-developer mailing list