[QGIS-Developer] Export PDFs from the processing modeler

[Olivier Dalang]

Hi,

I've setup together a quick prototype :
https://github.com/olivierdalang/processingpdf

It's a plugin that adds an "Export as PDF" algorithm.

You can have a look at the readme which provides a little bit more info.

There's a sample project including a processing model that uses the Export
to PDF algorithm to showcase what's possible (requires QGIS 3.3 + PR #7864)


So far, I sticked to my first intuition which was to use a project as the
starting point (rather than just a layout). The algorithm just allows to
"override" the datasource from layers in that project. The rationale is
that the project may contain relatively complex logic (atlas configuration,
table joins, etc...), and that this way, everything would (hopefully)
continue to work if it worked in the initial project.

If taking a layout as a starting point, we'd almost have to recreate
projects in the processing model, which would quickly be limiting or
over-complex. With "lock layers" and "lock styles", we could at least use
some predefined layers, but then it's much less practical to work with and
still isn't as flexible as using a whole project.


There's a few bugs in QGIS master that are a bit annoying (esp.
https://issues.qgis.org/issues/19836 that prevents the sample model to work
in batch mode), I'll try to see if I can figure out what's happening but
C++ isn't my cup of tea...

But besides this, no major technical limitation I think ! I've written down
a few ideas for next steps in the readme (short&longer term).

Let me know what you think !

Olivier




Le lun. 10 sept. 2018 à 11:43, Olivier Dalang <olivier.dalang at gmail.com> a
écrit :

> Thanks Nyall for you very interesting ideas.
>
> Initially, I thought of using layouts from QGIS projects rather than
> templates, as it makes it quite simple. You just create a normal QGIS
> project, setup styles, layout, enable or not atlas. The processing alg
> would just allows you to swap the datasource of one (or several) layers. It
> would make it very straightforward when using processing models embedded in
> the project file, and still relatively simple when using an external QGIS
> project.
>
> But looking at it again, it seems like it would be possible to achieve
> exactly the same thing with .qpt with "lock layers" and "lock styles" is
> ticked, as styles, layers and atlas settings are all saved in the .qpt.
>
> Remains the questions of the UI on how one would match input layers to
> existing layers in the qpt...
>
> About the utility algorithms, am I right understanding there are not
> directly linked to the PDF exporting algorithm (but just general helpers) ?
>
> The way forward I see is me trying to do a prototype as a python plugin
> (of course if you can help by reviewing, that would be awesome), and once
> stabilized, we can see how to move this to core (I personally am more at
> ease with python, but could probably try to move it to C++ if we think it's
> worth it and if you can mentor a little bit). That also allows to move
> forward without being too stressed by release dates / feature freezes (as
> there would be the python plugin).
>
> So it would be nice if you could share the python code you were talking
> about.
>
> Cheers,
>
> Olivier
>
>
>
>
>
>
> Le ven. 7 sept. 2018 à 11:27, Nyall Dawson <nyall.dawson at gmail.com> a
> écrit :
>
>> On Thu, 6 Sep 2018 at 14:16, Olivier Dalang <olivier.dalang at gmail.com>
>> wrote:
>> >
>> > Dear List,
>> >
>> > (I took the liberty to CC in some of you that I thought may be
>> interested by this)
>>
>> Count me in too -- I'm very interested here, given my history with
>> both Print Layout and Processing work!
>>
>> > 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)
>>
>> I've got (Python) code which allows Print Layout parameter choices
>> (exposed as a combo box showing layouts within the current project),
>> and a layout "map item" parameter (links to the print layout
>> parameter, and shows a nice combo box of map items in the selected
>> layout). I can clean this up and share, but honestly my preference
>> would be to get this in to master as c++ code.
>>
>> I think ideally the "print layout" parameter would expose both layouts
>> in the current project + a "..." file selector allowing choice of a
>> Print Layout template file (.qpt) (this should be relatively
>> straightforward -- basically a new temporary layout would be created
>> using the selected qpt). Possibly we could/should have an option in
>> that drop down to allow selection of a layout from a different project
>> file too, but this would add considerable complexity, and I'm unsure
>> if there's a concrete use case for this which couldn't be handled by
>> qpt template files alone.
>>
>> > - 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)
>>
>> There's already multi layer parameters available for algorithms (which
>> also support layer order), so these could be reused here.
>>
>> > Do you have some ideas about implementation ?
>>
>> I'd see a number of ways we could expose print layouts/atlas to
>> Processing. Some potential algorithms could be:
>>
>> Exporting algorithms
>> ---------------------------
>> - Export layout. Just does a direct export of the selected layout to a
>> specified file. Nice and easy! [1]
>> - Export atlas. As above, but for a pre-existing atlas and selected
>> folder/file destination.
>> - Something like "export layout as atlas", where users select and
>> existing layout/qpt, map item, and "coverage layer", and the algorithm
>> iterates over the features in that layer just like an atlas, but using
>> a map layer generated elsewhere in the model as the coverage layer.
>>
>> Utility algorithms
>> ----------------------
>> - Create layer from layout map item extent. Creates a new polygon
>> layer with a polygon feature of the are currently visible within a
>> selected layout map item. Handy for quickly creating a polygon layer
>> with the exact coverage of a map item for styling or atlas creation
>> purposes. (I've implemented this one already as a PyQGIS alg)
>> - Create atlas feature template: After selecting a layout map item and
>> specifying a desired "scale" and "origin point", the algorithm creates
>> a new polygon layer with a single feature of the required size which
>> makes the map item match the given scale [2]. The use case here is to
>> create the feature, then "copy and move" it multiple times over the
>> area of interest for an atlas.
>> - Some equivalent of the ESRI "Create strip map index"  tool/QGIS
>> PolyStrip plugin. Select a map item, desired scale, and line feature
>> layer and the algorithm creates rotated template features along the
>> lines to allow an atlas following the line. Options for overlap
>> margins, max map rotation, etc.
>>
>> Layout creation algorithms
>> -----------------------------------
>>
>> We could also have algorithms for assisting with editing/creating
>> layouts themselves, e.g. algorithms which created grids of guides,
>> grided layouts, etc. I'd LOVE LOVE LOVE a layout "spell check" tool!
>>
>> Anyway, count me in here. I'm interested in helping in whatever way
>> desired - I can either mentor someone else to code this, or would be
>> interested in doing it directly if there's a sponsor available.
>> Alternatively we could write up all the desired specs and run a crowd
>> funding campaign to raise funds!
>>
>> Nyall
>>
>> [1] Would work super-well with a potential "QGIS variable" parameter,
>> which displays as the QGIS variable editor and which would allow
>> tweaking of expression variables to inflence the map render
>> [2] I'd also like to see a proper parameter widget for "scale"
>> parameters, which uses the nice QGIS scale widget instead of just
>> direct number entry.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180913/718f9ddc/attachment-0001.html>