On Tue, Aug 14, 2018 at 8:52 PM, Vaclav Petras wrote:
>
> # and delete the rest
> rm ~/grassdata/nc_spm/par1
> rm ~/grassdata/nc_spm/par2
> rm ~/grassdata/nc_spm/par3
> rm ~/grassdata/nc_spm/par4
>
Of course `rm -r` here.
___
QGIS-Developer mailing
On Tue, Aug 14, 2018 at 7:10 PM, Nyall Dawson
wrote:
> On Tue, 14 Aug 2018 at 21:43, Rudi von Staden wrote:
> >
> > Hi all,
> >
> > The bottleneck in my script at the moment is the calculation of zonal
> stats using 'grass7:r.stats.zonal'. I thought I might speed things up by
> using
On Wed, 15 Aug 2018 at 02:19, C Hamilton wrote:
> ...and some of the shapes have been ported to the processing framework.
> Eventually all will be in processing
Great to hear! Some of this functionality is fundamental stuff which
would be lovely to include in a default QGIS install, and porting
On Tue, 14 Aug 2018 at 21:43, Rudi von Staden wrote:
>
> Hi all,
>
> The bottleneck in my script at the moment is the calculation of zonal stats
> using 'grass7:r.stats.zonal'. I thought I might speed things up by using
> QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these
>
On Tue, 14 Aug 2018 at 19:01, Jonathan Moules
wrote:
>
> Hi Nyall,
>
> Looking at this from another angle (and being aware I know nothing of
> the QGIS code-base) - to me at least that would suggest that maybe it's
> worth improving the crash dumps so that they're better able to be used
> as a
ShapeTools for QGIS 3 now has the ability to break lines, along a geodesic
path, into MultiLineString components when they cross the international
date line at -180,180 degrees. This fixes the issue that Anita addresses in
her blog post:
Hi all,
The bottleneck in my script at the moment is the calculation of zonal stats
using 'grass7:r.stats.zonal'. I thought I might speed things up by using
QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these
calculations in parallel. In my tests of both approaches the tasks seem
On 08/14/2018 11:21 AM, Matthias Kuhn wrote:
>
> Hi all,
>
> Can a new state "feedback required" be introduced (emphasis on
> required) which then can be closed automatically if no feedback is
> provided? This state would be set by humans when it's clear at the
> time of setting the state that
> I agree in general, but there's a lot of tickets recently with just a
> crash dump (with no clues in the dump) and no further info about how
> to reproduce the crash or what triggered it. These reports don't have
> *any* value on their own.
>
> Nyall
By the way, since log we have also a
Hi all,
Can a new state "feedback required" be introduced (emphasis on required)
which then can be closed automatically if no feedback is provided? This
state would be set by humans when it's clear at the time of setting the
state that the ticked not only *would like to have* but actually *does
Hi Nyall,
Looking at this from another angle (and being aware I know nothing of
the QGIS code-base) - to me at least that would suggest that maybe it's
worth improving the crash dumps so that they're better able to be used
as a stand-alone debugging thing that doesn't require user
On 08/14/2018 02:23 AM, Nyall Dawson wrote:
> On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini wrote:
>> I agree, better be conservative. Furthermore, not always lack of feedback
>> means an issue is not valid. I'd be against automatically closing the issues
>> without further verification.
> I
12 matches
Mail list logo
