Only use features within atlas feature does not seem to work on a Report

[rhewy]

Possible bug
When using a chart on a QGIS report (not print composer) the concept of an atlas feature does not seem to work. I can see the variable and I can see the setting on the chart but it does not seem have the desired effect.

To Reproduce
Load some layers

• One to drive the zoom to feature
• One to feed data to the chart
• Add the plugin dataplotly
• Create a Report (not a print composer atlas)
• Add a field group section
• Edit the above section's body
• Add a map (Map1)
• Set the map to controlled by report (this will get the zoom to work)
• Add a chart to the body (pie chart)
• Setup selected chart
• Check use features within atlas
• No chart when you export the the report

Screenshots

Environment:

• OS: Windows
• QGIS release 3.20.3
• DataPlotly release 3.8.1

Additional context
Add any other context about the problem here.

[ghtmtt]

Cannot reproduce the bug with a custom dataset. Do the layers have the same CRS?

[rhewy]

The layers are in a postgis enabled database.

• PostgreSQL 13.4
• POSTGIS="3.1.4 ded6c34" [EXTENSION]

The data is not in the public schema

Parks (layer driving the report):
CREATE TABLE IF NOT EXISTS gist_7132_m07.parks
(
pa_name character varying(60) COLLATE pg_catalog."default",
geom geometry(MultiPolygon,3005)
)

becpas2 (layer with the details)
CREATE TABLE IF NOT EXISTS gist_7132_m07.becpas2
(
becpas_id bigint NOT NULL,
geom geometry(MultiPolygon,3005),
area numeric,
perimeter numeric,
becpas_ bigint,
qbec_sq_ bigint,
qbec_sq_id bigint,
beclabel character varying(9) COLLATE pg_catalog."default",
fcn integer,
fcode character varying(10) COLLATE pg_catalog."default",
tpas_sq_ bigint,
tpas_sq_id bigint,
pa_name character varying(60) COLLATE pg_catalog."default",
orc_num character varying(4) COLLATE pg_catalog."default",
date character varying(30) COLLATE pg_catalog."default",
CONSTRAINT becpas2_pkey PRIMARY KEY (becpas_id)
)

The column they have in common is pa_name, however, the column is not explicitly set as a linking field.

Do I need to create a relationship in QGIS or an FK in PostgreSQL?

If I export the layers to a geopackage and we both test that, would that help?

[rhewy]

I just exported the data to a geopackage but I had to zip it to upload it.
See below:
data_report_dataplotly.zip

[rhewy]

What spatial predicate is being used for "inside atlas feature"?

Reason, many of my polygons would be covered by the atlas feature as they were dissolved to make the features for the atlas so the boundaries would touch.

[rhewy]

I am going to try an attribute approached. I will post the result here.

[rhewy]

If I take an attribute approach and on plot parameters set the feature subset, things seem to work:
"pa_name" = attribute(@atlas_feature, 'pa_name')

[rhewy]

If I reduce the polygons to centroids and on plot parameters under linked map and check "Use only features inside atlas feature" then things seem to work.

UPDATE - This may have seemed to work for another reason. The attribute table frame and the pie chart used the same source layer/table. The "Show only features intersecting report feature" option under feature filtering of the attribute table help out the pie chart and made it look like it was working. I will create a geopackage with an embedded project file with only the map and the pie chart on the report to see if I can isolate the issue.

[rhewy]

I can now get it to work with a geopackage fine. I will roll back to the postgis tables and see if the base format is causing the problem. Note, I did upgrade to the latest QGIS 3.22.0 this morning.

UPDATE - need to test more in a clean project to make sure about the "fine" part. Not so sure anymore, see my update to the post directly above this one

[rhewy]

Even with QGIS 3.22.0 when the layers are coming from PostgreSQL/PostGIS the plot goes missing on the report.

Below is the PDF report output.

park_veg_posgis_poly_v6_no_nulls_park_pk.pdf

Pie chart settings

[rhewy]

If I use the feature subset technique I can get the report to work with the layers coming from PostGreSQL/PostGIS.

Report attached:
park_veg_posgis_poly_v7_att_feat_sub.pdf

[rhewy]

Hi,

Just an update

Inside plot_layout_item.py class PlotLayoutItem method get_polygon_filter

I do get inside the elif 'layout_filter_by_atlas' part

Not sure about the following:
QgsMessageLog.logMessage(f'{self.layout().reportContext().layer()}')
QgsMessageLog.logMessage(f'{self.layout().reportContext().layer().crs()}')
I am try to log them to see if they are set but them seem blank???

[rhewy]

Hi.

Quick update, I can log out the SRID:
QgsMessageLog.logMessage(f'{self.layout().reportContext().layer().sourceCrs().postgisSrid()}')
However in the code I can see the line below a few times
self.layout().reportContext().layer().crs()

In the docs at https://qgis.org/api/classQgsLayoutReportContext.html
then at https://qgis.org/api/classQgsVectorLayer.html

I cannot find a crs() member function but maybe it is inherited?

[rhewy]

geopackage vs postgis

There is a difference. The difference seems to be in plot_factory.py in the class PlotFactory in the method fetch_values_from_layer.

In the elif for the polygon_filter the rectangle returned by ct.transformBoundingBox(self.polygon_filter.geometry.boundingBox()) is identical for both formats.

However, the features restricted but request.setFilterRect(rect) seems to differ (more for postgis and less for geopackage)

The test in the for-loop (for f in it) visible_geom_engine.intersects(...) gives a different result. No hits for postgis but hits for geopackage.

I could be wrong but the creation of the geom engine might be the place to look. QgsGeometry.createGeometryEngine(g.constGet())

The engine seems to treat the geometry from postgis differently than the geometry for geopackage.

[ghtmtt]

that's kind of weird. Geopackages might have some trouble with the fid vs primary key (see #236), but I wasn't aware of any geometrical difference. Not sure if @nyalldawson has some other idea.