Bug report #16899
Print composer: "none" value for the "map" option of a composer legend is not available anymore in 2.18.10 > no more fixed legends with QGIS Server GetPrint
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Map Composer/Printing | ||
| Affected QGIS version: | 2.18.16 | Regression?: | Yes |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | end of life |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 24798 |
Description
It was ok until at least 2.14.16
This has direct effect on how map legends can be printed using QGIS Server and a GetPrint request.
The general question/problem is:
how do I get a printed map via GetPrint where the legend is fixed regardless the layers listed in the request (that are the layers that are then visible within the map object)?
Well, the solution was using none as value for the map option for any legend object in QGIS print composer. In this way the legend was unlinked from any map object and as a result it was always printed (in a GetPrint request) as defined in the QGIS Desktop print composer options (of course with the "auto update" and the "filter" not enabled).
So with a request like:
where just 1 layer is requested to be visible in the map, we could get the legend also for all the other layers (as defined in the layout composer in QGIS):
https://www.dropbox.com/s/f1jtr2i8qfbm5sw/qgis_server_with_none_option.pdf?dl=0
When instead of "none" the legend is associated to a map object like "map0" then the result is different, only the symbology synbols/classes for requested layers are added to the legend:
https://www.dropbox.com/s/svgbmx8sor7jjuz/qgis_server_without_none_option.pdf?dl=0
In QGIS 2.18.10 the value "none" is no more available, not allowing to get anymore the first result presented above (again, this affect only the maps printed via QGIS Server with GetPrint)
Both the above examples are obtained using QGIS Server 2.18.10 on a project saved in 2.14.16, this shows the issue in QGIS Desktop print composer rather then the Server.
Moreover if instead the project is saved with QGIS Desktop 2.18.10, the result of the above request is different and looks wrong, with "?" shown instead of (at least) the layer names, as in the second case above linked:
https://www.dropbox.com/s/hfsvul4uy3h5uqa/qgis_server_without_none_option_2_18.pdf?dl=0
History
#1
Updated by Giovanni Manghi over 7 years ago
- Affected QGIS version changed from 2.18.10 to 2.18.11
#2
Updated by Giovanni Manghi almost 7 years ago
- Description updated (diff)
- Affected QGIS version changed from 2.18.11 to 2.18.16
#3
Updated by Giovanni Manghi almost 7 years ago
- Description updated (diff)
#4
Updated by Giovanni Manghi almost 7 years ago
This issue is still very much valid in the latest 2.18 and afaik it hasn't been addressed in QGIS 3.
In private exchange with Nyall the possible solution would be "adding a server settings section to the legend properties, with a checkbox "always show all layers (Regardless of requested layers)" (or betterly worded!)".
#5
Updated by Giovanni Manghi almost 7 years ago
- File Screenshot_20180123_181818.png added
- File Screenshot_20180123_181834.png added
- File Screenshot_20180123_182059.png added
Further tests:
1) on a Server with QGIS Server 2.14 is the same project is published 4 times: created/saved with QGIS Desktop 2.14 and with 2.18. For each case it was also saved once with "none" as value for the legend "map" option in the print composer. As in QGIS Desktop 2.18 the value "none" for the "map" option is no more available this was achieved by editing manually the QGIS project and removing map="0" from <ComposerLegend>
In any case the resulting legend in a GetPrint request looks as expected: legend only for layers passed in the GetPrint request when using "map0" and legend for all layers otherwise.
2) The same 4 projects are published on a server with QGIS Server 2.18 and a GetPrint request sent. Test projects have two layers named "freguesias" and "madeira_mdt_100".
Request example:
&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetPrint&FORMAT=pdf&EXCEPTIONS=application/vnd.ogc.se_inimage&TRANSPARENT=true&SRS=EPSG:3857&DPI=100&TEMPLATE=land_a4&map0:extent=-2092586.76645,3542886.327036,-1595074.80268,3875394.322923&map0:scale=2500000&map0:LAYERS=freguesias&map0:STYLES=default&LAYERS=freguesias&STYLES=default&OPACITIES=255
a) for projects saved with QGIS Desktop 2.14 the resulting legend is as expected.
legend "map" value set to "none":
the legend for the layer "madeira_mdt_100" is correctly shown despite not being passed in the GetPrint
legend "map" value set to "map0":
the layer name for of "madeira_mdt_100" show in legend but not its symbology (as expected, or at least as always has worked QGIS Server in this case)
a) for projects saved with QGIS Desktop 2.18 the resulting legend is as expected.
legend "map" value set to "none" or "map0":
instead of showing the legend/symbology for "madeira_mdt_100" ("none) or just its name ("map0") a question mark is shown
#6
Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from Open to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/
QGIS 3.4 has recently become our new Long Term Release (LTR) version. This is a major step in our history – a long term release version based on the massive updates, library upgrades and improvements that we carried out in the course of the 2.x to 3x upgrade cycle.
We strongly encourage all users who are currently using QGIS 2.18 LTR as their preferred QGIS release to migrate to QGIS 3.4. This new LTR version will receive regular bugfixes for at least one year. It also includes hundreds of new functions, usability improvements, bugfixes, and other goodies. See the relevant changelogs for a good sampling of all the new features that have gone into version 3.4
Most plugins have been either migrated or incorporated into the core QGIS code base.
We strongly discourage the continued use of QGIS 2.18 LTR as it is now officially unsupported, which means we’ll not provide any bug fix releases for it.
You should also note that we intend to close all bug tickets referring to the now obsolete LTR version. Original reporters will receive a notification of the ticket closure and are encouraged to check whether the issue persists in the new LTR, in which case they should reopen the ticket.
If you would like to better understand the QGIS release roadmap, check out our roadmap page! It outlines the schedule for upcoming releases and will help you plan your deployment of QGIS into an operational environment.
The development of QGIS 3.4 LTR has been made possible by the work of hundreds of volunteers, by the investments of companies, professionals, and administrations, and by continuous donations and financial support from many of you. We sincerely thank you all and encourage you to collaborate and support the project even more, for the long term improvement and sustainability of the QGIS project.