If you read above, the idea is to set fields *other then the ones selected
for grouping* null. So it wouldn't pick the first one, which is meaningless.
Having aggregate functions to be applied to single non-grouping fields
could be a great plus, keeping the option to leave the field set to null.
Hi,
I also think that the logical solution would be to aggregate the
attributes when grouping and allow the user to specify which aggregate
function to use for each attribute.
Just randomly using the attributes of the first feature doesn't really
makes sense to me. In 99% of the
Now that we
On 6/29/17 10:21 AM, G. Allegri wrote:
>
> 1. Allowing multiple field selection for grouping
> 2. Keeping attributes of first feature when grouping
>
>
> I will accept this criteria, obviously, if it's the preferred solution
> for the mosts.
> I just want to report that many users (partec
Side note: I would apply the same approach to all the "grouping"
algorithms, e.g. Dissolve.
giovanni
Il 29 giu 2017 10:54, "Paolo Cavallini" ha scritto:
> Il 29/06/2017 10:41, Anita Graser ha scritto:
>
> > Sounds OK to me if it is possible to select multiple grouping fields.
>
> +1
> thanks
>
Il 29/06/2017 10:41, Anita Graser ha scritto:
> Sounds OK to me if it is possible to select multiple grouping fields.
+1
thanks
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_
On Thu, Jun 29, 2017 at 10:32 AM, Nyall Dawson
wrote:
> On 29 June 2017 at 18:21, G. Allegri wrote:
> >
> > 1. Allowing multiple field selection for grouping
> > 2. Keeping attributes of first feature when grouping
> >
> >
> > I will accept this criteria, obviously, if it's the preferred solutio
On 29 June 2017 at 18:21, G. Allegri wrote:
>
> 1. Allowing multiple field selection for grouping
> 2. Keeping attributes of first feature when grouping
>
>
> I will accept this criteria, obviously, if it's the preferred solution for
> the mosts.
> I just want to report that many users (partecipan
1. Allowing multiple field selection for grouping
2. Keeping attributes of first feature when grouping
I will accept this criteria, obviously, if it's the preferred solution for
the mosts.
I just want to report that many users (partecipants to courses or
customers) say they find having the "first
Il 29/06/2017 08:33, Nyall Dawson ha scritto:
> On 28 June 2017 at 18:23, G. Allegri wrote:
>> The best of two (but there would be a bit of overhead for the algorithm):
>> set them to null as soon as two different values are found, keep the first
>> encountered value otherwise (all the features wi
On 28 June 2017 at 18:23, G. Allegri wrote:
> The best of two (but there would be a bit of overhead for the algorithm):
> set them to null as soon as two different values are found, keep the first
> encountered value otherwise (all the features with same value).
>
Ok - I've actually had a bit of
The best of two (but there would be a bit of overhead for the algorithm):
set them to null as soon as two different values are found, keep the first
encountered value otherwise (all the features with same value).
giovanni
2017-06-28 10:16 GMT+02:00 Anita Graser :
>
>
> On Wed, Jun 28, 2017 at
On Wed, Jun 28, 2017 at 9:53 AM, Nyall Dawson
wrote:
>
> Incidentally - how should we handle attributes here (and other similar
> algorithms)? Take the first feature's attributes? Drop all attributes?
>
>
I would take the first feature's attributes because I've seen multiple
times that input data
I would set them to null. In general I wouldn't change the dataset fields
schema along the processing steps, except in case of algorithms dedicated
to this.
The same happens with Dissolve.
giovanni
Il 28 giu 2017 09:53, "Nyall Dawson" ha scritto:
> On 28 June 2017 at 14:42, Paolo Cavallini wro
On 28 June 2017 at 14:42, Paolo Cavallini wrote:
> If we use the boolean as you suggested, I think the default should
> probably be all features.
That's fine by me.
Incidentally - how should we handle attributes here (and other similar
algorithms)? Take the first feature's attributes? Drop all
Il 28/06/2017 00:54, Nyall Dawson ha scritto:
> Ok - perhaps requiring only multipart feature inputs is too extreme. How
> about:
>
> 1. We drop the field group option, for the same reasons initially
> described (there's better algorithms to do this)
> 2. Add a new boolean option for which creat
On 28 June 2017 at 05:06, Anita Graser wrote:
>
>
>
> I absolutely understand the reason from an engineering point. From the user
> point - and as someone answering a lot of user questions - it is predictable
> that end users will be confused.
>
> Idea: Have a warning if a user tries to run the ne
Thanks Giovanni and sorry for keeping my last message so short that it
was hard to follow.
Yes, indeed, the proposal was that the user experience should be the
same as now. A dedicated entry (algorithm) in the toolbox with an option
for "group by attribute".
That this "algorithm" internally is a
I understand and agree on having "atomic" algorithms but I'm not sure if we
can always consider single features as the unique operating level. I know
this would bring benefits to the code engineering but we have to keep in
mind the end users expectations.
I agree with Mathias, probably we should h
On Tue, Jun 27, 2017 at 7:45 AM, Matthias Kuhn wrote:
> On 6/27/17 7:19 AM, Paolo Cavallini wrote:
>
> > Hi Nyall,
> >
> > Il 27/06/2017 01:41, Nyall Dawson ha scritto:
> >
> >>> This discussion relates to the "Convex Hull" algorithm. I'd like to:
> >>>
> >>> 1. Drop the "Field (optional, only us
It is important that convex hull is available for datasets
at the user interface level.
Håvard
On 27. juni 2017 07:19, Paolo Cavallini wrote:
Hi Nyall,
Il 27/06/2017 01:41, Nyall Dawson ha scritto:
This discussion relates to the "Convex Hull" algorithm. I'd like to:
1. Drop the "Field (opti
Il 27/06/2017 07:45, Matthias Kuhn ha scritto:
> Maybe there is the need to ship some often-used models by default then?
> Thinking of code complexity and maintainability, it makes much sense to
> modularize algorithm code as much as possible
agreed
thanks
--
Paolo Cavallini - www.faunalia.eu
Q
On 6/27/17 7:19 AM, Paolo Cavallini wrote:
> Hi Nyall,
>
> Il 27/06/2017 01:41, Nyall Dawson ha scritto:
>
>>> This discussion relates to the "Convex Hull" algorithm. I'd like to:
>>>
>>> 1. Drop the "Field (optional, only used if creating convex hulls by
>>> classes)" option and the accompanying
Hi Nyall,
Il 27/06/2017 01:41, Nyall Dawson ha scritto:
>> This discussion relates to the "Convex Hull" algorithm. I'd like to:
>>
>> 1. Drop the "Field (optional, only used if creating convex hulls by
>> classes)" option and the accompanying method choice used to set the
>> convex hull to 'creat
On 27 June 2017 at 09:38, Nyall Dawson wrote:
> Hi all,
>
> As you may be aware, I've been working on rebuilding the backend of
> Processing in c++ and refining how it operates.
>
> As part of this I'd like to clear up the list of existing algorithms
> and also refine how they behave. This list of
Hi all,
As you may be aware, I've been working on rebuilding the backend of
Processing in c++ and refining how it operates.
As part of this I'd like to clear up the list of existing algorithms
and also refine how they behave. This list of "QGIS" algorithms has
grown organically during the 2.x cyc
25 matches
Mail list logo
