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 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
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
(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
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 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
>
> 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
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 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
>
> 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)
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
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
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:
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:
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:
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:
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:
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 =
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
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:
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
21 matches
Mail list logo