Re: [QGIS-Developer] native XYZ layers - zoom level

[Olivier Dalang]

Fasiha I used the following steps :

- open the qgs project (xxx.qgs file) in a text editor
- find the layer definition (you can search for the URL you entered)
- add =17=22 to the URL

There are probably ways to add the parameters directly in the layer
definition in the brower, which is stored somewhere in QGIS preferences.

Bests,

Olivier


2017-06-29 2:03 GMT+00:00 fasiha :

> olivier wrote
> > Awesome that will perfectly do until 3.0.
>
> Olivier, could you elaborate just a bit on how to do this in 2.18? I’m a
> QGIS beginner, I can bring up the Python Console in QGIS, but then what
> function do I invoke that will create an XYZ tile layer where I can specify
> zmin/zmax?
>
> Thank you!
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/QGIS-Developer-native-XYZ-layers-zoom-level-
> tp5324030p5325931.html
> Sent from the QGIS - Developer mailing list archive at Nabble.com.
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [730] Line direction histogram approval notification.

[noreply]

Plugin Line direction histogram approval by pcav.
The plugin version "[730] Line direction histogram 2.2" is now approved
Link: http://plugins.qgis.org/plugins/LineDirectionHistogram/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [740] qgis2web approval notification.

[noreply]

Plugin qgis2web approval by pcav.
The plugin version "[740] qgis2web 2.21.1" is now approved
Link: http://plugins.qgis.org/plugins/qgis2web/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [408] shptoobs approval notification.

[noreply]

Plugin shptoobs approval by pcav.
The plugin version "[408] shptoobs 0.1.2 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/shp_to_obs/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [408] shptoobs approval notification.

[noreply]

Plugin shptoobs approval by pcav.
The plugin version "[408] shptoobs 0.1.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/shp_to_obs/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [408] shptoobs approval notification.

[noreply]

Plugin shptoobs approval by pcav.
The plugin version "[408] shptoobs 0.1.4 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/shp_to_obs/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [408] shptoobs approval notification.

[noreply]

Plugin shptoobs approval by pcav.
The plugin version "[408] shptoobs 0.1.6 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/shp_to_obs/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [408] shptoobs approval notification.

[noreply]

Plugin shptoobs approval by pcav.
The plugin version "[408] shptoobs 0.1.7 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/shp_to_obs/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] GDAL Support For PostGIS Out-DB Rasters

[Osahon Oduware]

Hi All,

Currently, QGIS-GDAL seems to be only able to display rasters that are
stored in the database as it displays a black image for PostGIS Out-DB
rasters as described in my post in the link below:
http://osgeo-org.1560.x6.nabble.com/QGIS-GDAL-OUT-DB-RASTER-SUPPORT-td5318735.html

*Please, I wanted to find out if there is any ongoing work towards
providing GDAL support for PostGIS Out-DB rasters or anyway to make QGIS
display PostGIS Out-DB rasters.*
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] parameter infos algorithm of Processing with python

[matteo]

Hi devs,

I'm making some test with Processing. I have a quick question: is there
a method to know (via python) the parameter of an algorithm?

To get one algorithm available as an object, I do:

import processing

# get an algorithm of the qgis provider, no matter which one
alg = qgis_list =
QgsApplication.processingRegistry().providerById("qgis").algorithms()[0]


to run this algorithm (of course) parameters are needed. The old

processing.runalg()

has been replaced with

processing.run()

but is there a way to know which parameter and the related information
have to be added in order to run it?

Thanks for any information!

Cheers

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[G. Allegri]

(I havent followed the work on QVariantMaps, I will give it a look).

Nyall, I know that to make it error free and mantainable, we will need some
sort of metadata, which would require some work both to set it up and
mantain it.
This dicussion starts from the benfits of having a schema. If the most of
you don't consider it a valuable option, there's no need to dicuss possible
implementation :)

I have various cases where I need to parse a project but I can't rely on
QGIS libs (because of the system environment).

If I had to decide for a solution I would considera, as said before, some
kind of metadata system, even something similar to doctests/docstrings
(skipped by compilers) where every class partecipating (or willing to
partecipate) to the serialization will declare it's sub-schema, and where
it would put it (we are always in an infoset model, so it must declare it's
parent).

A utility tool could parse the code and build the final, complete, scheme.
This utility could build whatever kind of scheme (XSD, DTD, our own
selfdescribing format).

Yes, this is an overhead for those working on the parts of the code that
serialize to project, but I don't think this is so big compared to the
benfits...
For sure we can't mantain a schema manually!

giovanni



2017-06-30 11:46 GMT+02:00 Nyall Dawson :

> On 30 June 2017 at 19:44, Matthias Kuhn   wrote:
> > On 06/30/2017 11:32 AM, G. Allegri wrote:
> >> Normally you start with a schema, and from that create xml. To me it
> >> sounds pretty hard to keep a schema updated the other way around?
> As the
> >> api can always add new/changed parts of xml in it?
> >>
> >>
> >> Even QgsProject won't know if a project is valid until all the delegated
> >> classes have tried to deserialize their own parts.
> >
> > Are you aware of real-world problems that were caused by this?
> >
> >>
> >> I think this is a weak point in QGIS, and it doesn't depend on the
> >> serialization format obviously.
> >
> > I think it's only XML that comes with all these metadescription systems
> > like DTD and XSD. I haven't seen anything similar for yaml and json.
>
> Also, on a related note - I'd prefer to see more areas of code move to
> the approach of serializing/deserialising to QVariantMaps and using
> your recent work on auto converting the maps to XML. It's much less
> maintenance this way :)
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[Nyall Dawson]

On 30 June 2017 at 19:39, G. Allegri  wrote:
>> Seems like a huge amount of administrative overhead to me. A small
>> change to the project format could result in massive amounts of
>> required changes to the xsd.
>>
>> Given that now it's safe to have multiple QgsProjects at once,
>> couldn't you instead just load the project and retrieve the desired
>> information using the QGIS API directly?
>
>
> Yes Nyall, it's ok until you can use the QGIS API :)
> You know that system integration often must rely on standard formats to
> exchange information in a decoupled way.
> QGIS is more often integrated in heterogeneous environments where it's not
> always possible (or it would be an overhead) to install and use QGIS libs.

I'm curious to how usable this will be still - given that the project
format can vary even between minor point releases. How do you plan to
practically be able to parse QGIS files? Even server (with the source
included along with the main QGIS source) tried this approach and
found it ultimately unworkable.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[Matthias Kuhn ]

On 06/30/2017 11:32 AM, G. Allegri wrote:
> Normally you start with a schema, and from that create xml. To me it
> sounds pretty hard to keep a schema updated the other way around? As the
> api can always add new/changed parts of xml in it?
> 
> 
> Even QgsProject won't know if a project is valid until all the delegated
> classes have tried to deserialize their own parts.

Are you aware of real-world problems that were caused by this?

> 
> I think this is a weak point in QGIS, and it doesn't depend on the
> serialization format obviously.

I think it's only XML that comes with all these metadescription systems
like DTD and XSD. I haven't seen anything similar for yaml and json.

They normally just have a descriptive API doc if intended to be
handwritten or not much at all if machine-written / machine-read.


I think the main upside of XSD etc. is if it's intended to be an
interoperable standard (.sld et al) where a consortium first defines the
format and then implementations follow. The tradeoff is that development
takes much more time and innovation is decreased.

Matthias
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[G. Allegri]

>
> Seems like a huge amount of administrative overhead to me. A small
> change to the project format could result in massive amounts of
> required changes to the xsd.
>
> Given that now it's safe to have multiple QgsProjects at once,
> couldn't you instead just load the project and retrieve the desired
> information using the QGIS API directly?
>

Yes Nyall, it's ok until you can use the QGIS API :)
You know that system integration often must rely on standard formats to
exchange information in a decoupled way.
QGIS is more often integrated in heterogeneous environments where it's not
always possible (or it would be an overhead) to install and use QGIS libs.


giovanni


>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[G. Allegri]

>
> Normally you start with a schema, and from that create xml. To me it
> sounds pretty hard to keep a schema updated the other way around? As the
> api can always add new/changed parts of xml in it?
>

Yes, that's hard, but it's quite odd to have a project serialization format
(in this case XML) without ever knowing how it will be until you don't
create it through some APIs. Isn't it?

Even QgsProject won't know if a project is valid until all the delegated
classes have tried to deserialize their own parts.

I think this is a weak point in QGIS, and it doesn't depend on the
serialization format obviously.

The only automatic way to obatin and XSD would be to make each contributing
class declare (somehow) what and how it will write it, and a metadata
system to let an utility grab all the declarations to build the XSD.
It's not an easy task, and it would require a lot of additions to each
class, but this would be the only strong way to obtain a (potentially)
error free and up to date schema.

Otherwise we sould manually build a test project on each release, the most
complete one, and manually check the differences...

giovanni



>
> Would it be a strange idea to move to another way of defining a project?
> Not to follow follow file format hypes and go to json, yaml or so, but
> if we could abstract this 'serialization' of a state of classes etc in a
> different way, could make it maybe easier to cut the (becoming bigger
> and bigger) project files in parts like:
> - datasource info, styling info, layerorder/extent info, other
>
>
I've done some test with GraphQL :)

giovanni
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[Nyall Dawson]

On 30 June 2017 at 18:35, G. Allegri  wrote:
>
> Hi everybody,
> I know this has been discussed in the past, and maybe I missed more recent 
> discussions, but I think this is a point that should be considered.
>
> Working a lot with QGIS projects parsing and processing, we have to rely on 
> trials and errors to validate a QGIS project and create test projects on 
> every QGIS release to verify our paresers to be aligned with each version.
>
> I see that a very old (15 years) Qgis.xsd is still in the QGIS sources [1].
>
> First of all I would get rid of it, being outdated and (I guess) unused.
> Then I would remove the DOCTYPE declaration from the project XML and use a 
> Schema declaration instead, pointing to a versioned XSD.
>
> XSDs could have their own versioning scheme, or keep it simple and let XSD 
> versions be strictly the same as QGIS's version (reported inside the project 
> file).
>
>
> What's your opinion on this?

Seems like a huge amount of administrative overhead to me. A small
change to the project format could result in massive amounts of
required changes to the xsd.

Given that now it's safe to have multiple QgsProjects at once,
couldn't you instead just load the project and retrieve the desired
information using the QGIS API directly?

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[Richard Duivenvoorde]

On 30-06-17 10:45, Matthias Kuhn  wrote:
> Hi Giovanni,
> 
> On 06/30/2017 10:35 AM, G. Allegri wrote:
>> Hi everybody,
>> I know this has been discussed in the past, and maybe I missed more
>> recent discussions, but I think this is a point that should be considered.
>>
>> Working a lot with QGIS projects parsing and processing, we have to rely
>> on trials and errors to validate a QGIS project and create test projects
>> on every QGIS release to verify our paresers to be aligned with each
>> version.
> 
> I mostly use the API (which is much more stable than the project file
> format) when I need to work with a project file.
> 
>> I see that a very old (15 years) Qgis.xsd is still in the QGIS sources [1]. 
> 
> I noticed that one as well and wouldn't mind to dump it.
> 
>>
>> First of all I would get rid of it, being outdated and (I guess) unused.
>> Then I would remove the DOCTYPE declaration from the project XML and use
>> a Schema declaration instead, pointing to a versioned XSD.
>>
>> XSDs could have their own versioning scheme, or keep it simple and let
>> XSD versions be strictly the same as QGIS's version (reported inside the
>> project file).
> 
> 
> Having an .xsd sounds like a good thing to have. What would you need to
> maintain such a file?

Some related historical notes:

[0]
http://osgeo-org.1560.x6.nabble.com/QGIS-Server-Enhance-http-qgis-org-wms-1-3-0-xsd-and-WMS-1-3-0-compliance-td5175785.html

[1] https://issues.qgis.org/issues/4408

Normally you start with a schema, and from that create xml. To me it
sounds pretty hard to keep a schema updated the other way around? As the
api can always add new/changed parts of xml in it?

Would it be a strange idea to move to another way of defining a project?
Not to follow follow file format hypes and go to json, yaml or so, but
if we could abstract this 'serialization' of a state of classes etc in a
different way, could make it maybe easier to cut the (becoming bigger
and bigger) project files in parts like:
- datasource info, styling info, layerorder/extent info, other

Which would then make it easier to port a project file to one datasource
to another (and keeping the id's)...

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS project XSD

[Matthias Kuhn ]

Hi Giovanni,

On 06/30/2017 10:35 AM, G. Allegri wrote:
> Hi everybody,
> I know this has been discussed in the past, and maybe I missed more
> recent discussions, but I think this is a point that should be considered.
> 
> Working a lot with QGIS projects parsing and processing, we have to rely
> on trials and errors to validate a QGIS project and create test projects
> on every QGIS release to verify our paresers to be aligned with each
> version.

I mostly use the API (which is much more stable than the project file
format) when I need to work with a project file.

> I see that a very old (15 years) Qgis.xsd is still in the QGIS sources [1]. 

I noticed that one as well and wouldn't mind to dump it.

> 
> First of all I would get rid of it, being outdated and (I guess) unused.
> Then I would remove the DOCTYPE declaration from the project XML and use
> a Schema declaration instead, pointing to a versioned XSD.
> 
> XSDs could have their own versioning scheme, or keep it simple and let
> XSD versions be strictly the same as QGIS's version (reported inside the
> project file).


Having an .xsd sounds like a good thing to have. What would you need to
maintain such a file?

Matthias
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS project XSD

[G. Allegri]

Hi everybody,
I know this has been discussed in the past, and maybe I missed more recent
discussions, but I think this is a point that should be considered.

Working a lot with QGIS projects parsing and processing, we have to rely on
trials and errors to validate a QGIS project and create test projects on
every QGIS release to verify our paresers to be aligned with each version.

I see that a very old (15 years) Qgis.xsd is still in the QGIS sources [1].

First of all I would get rid of it, being outdated and (I guess) unused.
Then I would remove the DOCTYPE declaration from the project XML and use a
Schema declaration instead, pointing to a versioned XSD.

XSDs could have their own versioning scheme, or keep it simple and let XSD
versions be strictly the same as QGIS's version (reported inside the
project file).


What's your opinion on this?
Giovanni

[1] https://github.com/qgis/QGIS/blob/master/src/Qgis.xsd
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing 3.0: Possible change to the Convex Hull algorithm

[G. Allegri]

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.

What kind of aggregate functions do we have for categorical/textual values?

giovanni

Il 30 giu 2017 08:36, "Neumann, Andreas"  ha scritto:

> 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 have aggregate functionality in QGIS - are there technical
> reasons for not using these aggregate functions?
>
> Just a hint, because about 1 year ago we paid Nyall for these aggregate
> functions and of course we are interested that these are used more and more
> in QGIS ;-)
>
> BTW: FME from safe software has an aggregate widget/functionality
> available whenever something is grouped. QGIS should do the same. I don't
> see why not.
>
> Andreas
>
> On 2017-06-30 07:47, Matthias Kuhn wrote:
>
> 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 (partecipants to courses or
> customers) say they find having the "first feature value" misleading.
> I agree with them. I would set the field values only for the grouping
> fields, having the same value within the group, and set null for the other
> fields.
>
> The problem raises during a long workflow. At some point you obtain a
> dataset with unconsisten field values, and it's not always obvious to know
> when and.which field value was set miningless.
>
>
> In the long run the most flexible solution will be to allow specifying the
> aggregate function applied to each field individually ("first/any", "mean",
> "mode", "max"...).
>
> No worries if it's not implemented right now, but please keep the code
> modular enough to introduce this easily later down the road. Without
> manually editing each algorithm that supports grouping.
>
> A possible approach to this would be a parameter
> "ParamterFieldAggregation" that offers a standard gui to configure the
> aggregation behavior (fieldA: min; fieldB: mean; fieldC: any; fieldD:
> mean(expression("numBirds2017 - numBirds2000")) ).
>
> Matthias
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing 3.0: Possible change to the Convex Hull algorithm

[Neumann, Andreas]

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 have aggregate functionality in QGIS - are there technical
reasons for not using these aggregate functions? 

Just a hint, because about 1 year ago we paid Nyall for these aggregate
functions and of course we are interested that these are used more and
more in QGIS ;-) 

BTW: FME from safe software has an aggregate widget/functionality
available whenever something is grouped. QGIS should do the same. I
don't see why not. 

Andreas 

On 2017-06-30 07:47, Matthias Kuhn wrote:

> 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 (partecipants to courses or customers) 
> say they find having the "first feature value" misleading.  
> I agree with them. I would set the field values only for the grouping fields, 
> having the same value within the group, and set null for the other fields. 
> 
> The problem raises during a long workflow. At some point you obtain a dataset 
> with unconsisten field values, and it's not always obvious to know when 
> and.which field value was set miningless.

In the long run the most flexible solution will be to allow specifying
the aggregate function applied to each field individually ("first/any",
"mean", "mode", "max"...).

No worries if it's not implemented right now, but please keep the code
modular enough to introduce this easily later down the road. Without
manually editing each algorithm that supports grouping.

A possible approach to this would be a parameter
"ParamterFieldAggregation" that offers a standard gui to configure the
aggregation behavior (fieldA: min; fieldB: mean; fieldC: any; fieldD:
mean(expression("numBirds2017 - numBirds2000")) ). 

Matthias

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer