Il 14/09/2015 11:21, Bernhard Ströbl ha scritto:
> Hi Arnaud,
Hi all,
I'm so glad of this spur of interest in the analytical capabilities of
QGIS! I often felt lonely, seeing that comparatively little resources
are invested in this important area. I frankly think we are understaffed
on this, and w
Hi Arnaud,
I would like add two things to (the end of) your list:
* Have a way to add icons to the algorithms
* Improve (and translate) algorithms' documentation
Bernhard
Am 14.09.2015 um 10:30 schrieb Arnaud Morvan:
Normally, I would be present at next hackfest and interested in working
on th
Normally, I would be present at next hackfest and interested in working
on this.
From my point of view, the task would be:
* Create a customizable vector menu based on Processing like proposed
by Victor at Nodebo
* List fTools menu entries, with candidates Processing algorithms, and
dif
Hi Matthias,
sorry, I was not aware that new algorithms currently get implemented in
both, fTools and Processing (same for bug fixes). This may be because of
my ignorance, as I only adressed Processing with both, bug fixes and new
algorithms since it had been introduced.
Bernhard
Am 14.09.2
Hi Bernhard
On 09/14/2015 09:39 AM, Bernhard Ströbl wrote:
> Hi Matthias,
>
> Am 14.09.2015 um 09:31 schrieb Matthias Kuhn:
>> Hi Bernhard,
>>
>> The current code redundancy does have some severe issues like:
>>
>> * Algorithms may give different results from the vector menu and
>> processing (
Hi
Side note: that are now some ogr2ogr based equivalent algorithms available,
that on average have significantly better performance than their ftools
counterparts. Up until recently the absence of virtual vectors in
Processing did not allow creating algorithms requiring two or more layers.
But th
Hi Matthias,
Am 14.09.2015 um 09:31 schrieb Matthias Kuhn:
Hi Bernhard,
The current code redundancy does have some severe issues like:
* Algorithms may give different results from the vector menu and
processing (although both labelled similar, [QGIS] Geoprocessing)
I would need hints on ti
Hi Bernhard,
The current code redundancy does have some severe issues like:
* Algorithms may give different results from the vector menu and
processing (although both labelled similar, [QGIS] Geoprocessing)
* Bugs need to be fixed twice
* Features need to be implemented twice
If I remember ri
Hi Paolo,
just a thought: AFAIK fTools does not use 3rd party backends, so the
question of bulletproofness in conjunction with fTools IMHO should only
be raised for those algorithms that are currently in "QGIS
geoalgorithms". (Otherwise I fully agree: the rest should work flawlessly)
As I said
I think Arnaud also raised the question sometime ago (my fault for not
commenting on that at the time...), and it should be easy to add those
shortcuts, but I haven't had much time lately for working on
Processing.
I wont be attending the next Hackfest, but sounds like a task that can
be accomplis
Il 11/09/2015 11:29, kimaidou ha scritto:
> +1 for this !
Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we better
be careful before removing fTools, because:
* people are used to it, and for one-shot analy
+1 for this !
2015-09-11 11:18 GMT+02:00 Bernhard Ströbl :
> Hi all,
>
> I recently recoded Processing's Dissolve. The changes fundamentally
> reduced the runtime of the algorithm. In the pull request discussion [1]
> Matthias and I came to a point where we were wondering about the future of
> fT
Hi all,
I recently recoded Processing's Dissolve. The changes fundamentally
reduced the runtime of the algorithm. In the pull request discussion [1]
Matthias and I came to a point where we were wondering about the future
of fTools and Processing. I found this discussion from May [2]. What is
13 matches
Mail list logo
