[QGIS-Developer] Export PDFs from the processing modeler

[Olivier Dalang]

Dear List,

(I took the liberty to CC in some of you that I thought may be interested
by this)

I'm dreaming of using the QGIS graphical modeler to output PDFs using print
composers. This would allow to build very interesting report generators
using our favorite tool. As far as I understand, currently, it is not
possible.

I'd be interested in working to implement it, to start with as a plugin
(prototype), and once this works see if we can integrate into core.

What I thought of so far is to be able to specify as inputs :
- a QGIS project [file] (using the current project if empty - esp. useful
in conjunction with the great new embedded models feature)
- a composer name [string] (use the first one if empty)
- N layers [layer] (I don't think we can support variable inputs count, so
could be 5)
- N layer ids [string] (id of the layer in the project to be replaced by
corresponding input)

The algorithm would replace the datasources from the file, and then export
the pdf somehow (yet to be determined how, but there seem some good
resources  around this).

I'm not sure it's the best way... I especially don't really like the use of
layer ids (as they are not easy to find). Maybe layer name would be better
(even if there may be duplicates, but the user has control on the QGIS
project so that may be acceptable).

Has anyone done any work that goes in that direction ?

Do you have some ideas about implementation ?

Cheers,

Olivier
___
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] Anyone using QGIS with high resolution screen?

[Nyall Dawson]

On Thu, 6 Sep 2018 at 03:39, Denis Rouzaud  wrote:
>
> Hi list,
>
> There is a persistent issue of slowness of QGIS on Mac.
> https://issues.qgis.org/issues/19546
>
> The last comments led to think that this comes from high resolution. Starting 
> from 2560x1440, it starts to be less and less usable. And completly unsuable 
> at 5120x2880.

3840x2160 here, on Linux/Win, and perfectly usable. That's the highest
res I've got available to test with.

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] Handle Bad Layers

[Nyall Dawson]

On Thu, 6 Sep 2018 at 05:42, Worth Lutz  wrote:
>
> Hi Devs,
>
> I have a question about the "Handle Bad Layers" dialog. My scenario is 
> working offline and loading a project with WMS layers defined. As the WMS is 
> unreachable, the layers are marked as "bad". Since the layers are not fixable 
> while offline, they get deleted from the project.
>
> I would like to continue to edit the layers locally stored on my laptop and 
> not lose the definitions of the WMS layers when saving the project.
>
> I would like to see the "bad" layers marked as "disabled because bad" and not 
> deleted from the project. This would keep the stored information about the 
> layer in the project. When the project is next opened while connected to the 
> internet these layers would be available without having to enter them again.
>
> Is there currently a way to do this?  Or should I add an enhancement request 
> issue for this idea?

I think this is a widely desired feature, and something I'd very much
like to see available "out of the box".

For 2.x there is a plugin "changeDataSource" which allows this
behavior. I don't think that plugin is available for 3.x yet.

Nyall

>
> --
> Worth Lutz
>
>
> ___
> 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] Handle Bad Layers

[Worth Lutz]

Hi Devs,

I have a question about the "Handle Bad Layers" dialog. My scenario is 
working offline and loading a project with WMS layers defined. As the 
WMS is unreachable, the layers are marked as "bad". Since the layers are 
not fixable while offline, they get deleted from the project.


I would like to continue to edit the layers locally stored on my laptop 
and not lose the definitions of the WMS layers when saving the project.


I would like to see the "bad" layers marked as "disabled because bad" 
and not deleted from the project. This would keep the stored information 
about the layer in the project. When the project is next opened while 
connected to the internet these layers would be available without having 
to enter them again.


Is there currently a way to do this?  Or should I add an enhancement 
request issue for this idea?


--
*Worth Lutz*


___
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] Anyone using QGIS with high resolution screen?

[Denis Rouzaud]

Hi list,

There is a persistent issue of slowness of QGIS on Mac.
https://issues.qgis.org/issues/19546

The last comments led to think that this comes from high resolution.
Starting from 2560x1440, it starts to be less and less usable. And
completly unsuable at 5120x2880.

I'd like to know if someone is using such resolution on another OS to be
sure that this is Mac specific (and if I need a 5K screen ;) ).

Thanks a lot,

Denis
-- 

Denis Rouzaud
de...@opengis.ch  
+41 76 370 21 22
___
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] Feature freeze / exemptions

[Matthias Kuhn]

Thanks Paolo

On 09/05/2018 09:02 AM, Paolo Cavallini wrote:
> Hi Matthias
>
>
> Il 09/05/2018 08:35 AM, Matthias Kuhn ha scritto:
>> I think the approach to let voting members decide as we did last time
>> (https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions) works fine.
>>
>>  * This committee includes several technical members
>>  * Everyone is free to vote or not, based on self-evaluation of knowledge
> it makes sense to me - perhaps this should be particularly stressed in
> the voting question, otherwise people will feel obliged to vote (which
> often means +1) even when they cannot grasp the implication.

Yes, we can state that explicitly.

In the past, e.g. here
https://www.loomio.org/p/BPc3Wj6l/duplicate-feature-redigitized we had
33% participation. Not sure what the reason for abstaining was, one
assumption would be that many did not feel comfortable enough to make a
decision. Or pure lazyness or disinterest ;P

Regards


___
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] Feature freeze / exemptions

[Paolo Cavallini]

Hi Matthias


Il 09/05/2018 08:35 AM, Matthias Kuhn ha scritto:
>
> I think the approach to let voting members decide as we did last time
> (https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions) works fine.
>
>  * This committee includes several technical members
>  * Everyone is free to vote or not, based on self-evaluation of knowledge
it makes sense to me - perhaps this should be particularly stressed in
the voting question, otherwise people will feel obliged to vote (which
often means +1) even when they cannot grasp the implication.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis

___
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] What to do about WFS test failures?

[Nyall Dawson]

On Sat, 1 Sep 2018 at 19:56, Nyall Dawson  wrote:

> 2. I think there may be a real issue here - I've got at least one
> customer who is having WFS issues with 3.2 and master. BUT: on the
> other hand Travis has always been flaky with any test which uses
> threads, regardless of which area of code it's from. So it could just
> be Travis playing up again, in which case we'd need to disable these
> tests like we do most of the other thread-related tests...

For those following at home -- I think the underlying issue (a bug)
has been found and fixed... fingers crossed!

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] Feature freeze / exemptions

[Matthias Kuhn]

Hi Paolo

On 09/05/2018 07:52 AM, Paolo Cavallini wrote:
> Hi Matthias,
>
> Il 09/05/2018 07:13 AM, Matthias Kuhn ha scritto:
>> Feature freeze is coming end of next week with a freeze window of 6
>> weeks. In the past, we have regularly granted freeze exemptions to
>> some features upon request.
>>
>> I think it would be good to know, what we can expect this time to
>> decide on what is granted and then send them over to Loomio for review.
>>
>> Myself, I would like to include Geometry Validation
>> (https://github.com/qgis/QGIS-Enhancement-Proposals/issues/131). I
>> estimate will require about 1 to maximum 2 more week to get it into a
>> mergeable state, which will still leave us with 4-5 weeks of bugfixing
>> time for this code. One part of it is, it will revisit some of the
>> geometry checker code which is corrected for threading and other
>> issues, so that can already be seen as "bugfixing of existing code"
>> that will land as part of it.
>>
> thanks for this request - this is indeed a gray area that has caused
> some discomfort in the past, so it will be good to have more clear
> guidelines. I think it will be difficult to carve them in stone however;
> some ad hoc evaluation will be necessary.
> Maybe we can ask three questions:
> * should we set a hard limit for freeze (e.g. no exemption in the last X
> weeks), or we can decide anytime based on the merit of the code submitted?
> * whom should decide on this? I personally think core developers should
> have a much heavier weight in this decision than PSC
> * based on which (more or less objective) criteria? This could include
> isolation of code,  i.e. likelihood that it will break other parts,
> importance of the new feature for the majority of users, quality of the
> code, commitment to promptly fix bugs.
> All the best.
>

I think the approach to let voting members decide as we did last time
(https://www.loomio.org/d/38Aiya0q/3-0-soft-freeze-exemptions) works fine.

 * This committee includes several technical members
 * Everyone is free to vote or not, based on self-evaluation of knowledge
 * Particular questions concerning the mentioned gray area can be
formulated on a case-by-case basis

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] Feature freeze / exemptions

[Saber Razmjooei]

In that case, would it be possible to postpone the feature freeze by 2
weeks and set it as a hard(ish) deadline?
Cheers
Saber


On Wed, 5 Sep 2018 at 06:56, Nyall Dawson  wrote:

> On Wed, 5 Sep 2018 at 15:13, Matthias Kuhn  wrote:
> >
> > Feature freeze is coming end of next week with a freeze window of 6
> weeks. In the past, we have regularly granted freeze exemptions to some
> features upon request.
> >
> > I think it would be good to know, what we can expect this time to decide
> on what is granted and then send them over to Loomio for review.
> >
> > Myself, I would like to include Geometry Validation (
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/131). I
> estimate will require about 1 to maximum 2 more week to get it into a
> mergeable state, which will still leave us with 4-5 weeks of bugfixing time
> for this code. One part of it is, it will revisit some of the geometry
> checker code which is corrected for threading and other issues, so that can
> already be seen as "bugfixing of existing code" that will land as part of
> it.
>
> I would also like to pre-emptively apply for a freeze exemption for
> the work detailed in
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/114 and
> currently the target of the crowd funding campaign at
>
> https://north-road.com/edit-features-in-place-using-qgis-spatial-operations-campaign/
>
> The fund raising is proceeding nicely and I believe this work will be
> successfully funded, and I'd love to get it in for 3.4. I'd estimate
> 1-2 weeks post freeze for merge.
>
> 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



-- 
Saber Razmjooei
www.lutraconsulting.co.uk
+44 (0)7568 129733
___
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