Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to display spatial filter extents on the map #45

Closed
rcoup opened this issue Dec 3, 2021 · 9 comments
Closed

Option to display spatial filter extents on the map #45

rcoup opened this issue Dec 3, 2021 · 9 comments

Comments

@rcoup
Copy link
Member

rcoup commented Dec 3, 2021

If a user has spatial filter(s) set, would be good to be able to (optionally) see the borders of the filters on the map.

IMO ideally they wouldn't appear as layers, but maybe more like a decoration (ie: layout extents, grids, etc)? Maybe @hamishcampbell has other ideas?

@rcoup rcoup changed the title Display spatial filter extents on the map Option to display spatial filter extents on the map Dec 3, 2021
@volaya
Copy link
Contributor

volaya commented Dec 3, 2021

The common practice in that case is not to use a layer, but a rubberband (using the QgsRubberBand class), which will be painted on the map canvas, and works as a decoration.

@hamishcampbell
Copy link
Member

That would be ideal.

@volaya
Copy link
Contributor

volaya commented Dec 7, 2021

This is already implemented. Now the layers from a repo with a spatial filter will have the filter bounding box drawn in the map canvas

image

In the repo properties, you can disable that or change the color used to paint the bounding box

image

Let me know what you think

@volaya
Copy link
Contributor

volaya commented Dec 7, 2021

Rubber bands are not reprojected on-the fly when the user changes the CRS of the map canvas, but I added the code to reproject them when that happens, so they should stay in place even if the canvas changes its properties.

When the layer is removed, the bounding box is deleted.

@rcoup
Copy link
Member Author

rcoup commented Dec 7, 2021

Looks good — I'd suggest making the lineweight thinner/less dense, and maybe add a label with the repo title, since if you're working with layers from multiple repos you could have multiple active filters?

eg (but more subtle):
CleanShot 2021-12-07 at 12 11 02

What do you think @brentneave?

@brentneave
Copy link

Yes that makes sense @rcoup. I suppose the main thing, if we change the styling of the spatial filter boundary, might be making sure it remains visually distinct from any layer geometry it might enclose or overlap.

@edcorkery
Copy link
Member

@timdenee export step handling is relevant

@volaya
Copy link
Contributor

volaya commented Dec 8, 2021

Adding text in the canvas is available from QGIS 3.22, with annotation layers. Instead of using that, I have used the classic canvas annotations, but removing the frame and the background, so they look like normal text labels. Later we can move to annotation layers, which will give us more control over the rendering and the styling of the text.

Using annotations makes things a bit more complex, since those are saved in the project (unlike rubber bands), so it is a bit tricky to handle kart layers in a saved QGIS project. Annotations object names are not saved, so there is no way to later identify an annotation as belonging to a kart repo filter (to hide it or show it according to what the user selects). What I have done is to prefix the label name with "kart:", so we can easily identify it when a project is opened and have full control over its rendering.

I think the code is working fine now in all these cases, but please test and let me know what you think.

Also, now it will not add multiple rubberbands if there are multiple layers from the same repo. It will just render one bounding box per repo.

@rcoup
Copy link
Member Author

rcoup commented Dec 14, 2021

Looks great :-)

@rcoup rcoup closed this as completed Dec 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants