[QGIS-Developer] Export PDFs from the processing modeler

Olivier Dalang olivier.dalang at gmail.com
Sun Sep 9 16:43:57 PDT 2018


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/20180910/4756b603/attachment.html>


More information about the QGIS-Developer mailing list