Skip to content

Conversation

@skinkie
Copy link

@skinkie skinkie commented Jul 28, 2025

Implements: #219

A common feature in interactive maps is the ability to click and retrieve the feature located beneath the mouse cursor. This functionality is already integrated in many other MapLibre interfaces, and this commit attempts to bring similar support to the Qt interface.

Due to the use of private structures, several forwarding methods were necessary — something I'm not particularly fond of. A review of this approach is recommended to see if a cleaner solution can be found.

Additional include directives were added in CMakeLists.txt to ensure proper MOC generation. It would be worth reviewing whether these can be simplified.

An example has been added which allows users to click on the map and retrieve feature properties. Currently, the mouse event interface directly provides coordinates, which is not ideal for this use case. We may need to revise the API to accommodate this more appropriately.

Note that the features returned are of type mbgl::Feature. It’s worth considering whether this is what the end-user expects.

skinkie and others added 2 commits July 29, 2025 01:08
Implements: maplibre#219

A common feature in interactive maps is the ability to click and
retrieve the feature located beneath the mouse cursor. This
functionality is already integrated in many other MapLibre
interfaces, and this commit attempts to bring similar support to
the Qt interface.

Due to the use of private structures, several forwarding methods
were necessary — something I'm not particularly fond of. A review
of this approach is recommended to see if a cleaner solution can
be found.

Additional include directives were added in CMakeLists.txt to
ensure proper MOC generation. It would be worth reviewing whether
these can be simplified.

An example has been added which allows users to click on the map
and retrieve feature properties. Currently, the mouse event
interface directly provides coordinates, which is not ideal for
this use case. We may need to revise the API to accommodate this
more appropriately.

Note that the features returned are of type mbgl::Feature. It’s
worth considering whether this is what the end-user expects.
@birkskyum
Copy link
Member

Since this will cause merge conflicts with the changes in the large upcoming modernization refactor

It's probably best to change the merge target of this PR from the "main" branch to "opengl-2" compatibility branch, and then we can move these changes to the main when the large pr is merged in.

@skinkie
Copy link
Author

skinkie commented Jul 31, 2025

Do you have an ETA on the merging into the main branch?

@ntadej
Copy link
Collaborator

ntadej commented Jul 31, 2025

I think this one will go in first.

@skinkie
Copy link
Author

skinkie commented Jul 31, 2025

I think this one will go in first.

I actually meant when the work of @birkskyum will be merged. As discussed with @ntadej yesterday; I would argue that it would be more optimal to either change the current API's (for the widget) or bring in a better facade for this feature. As translating to lat- lon then from lat-lon back to pixels to do a box is very imprecise.

Due to my issues with Shiboken my own signature now looks like:

 QMap<QString, QMap<QString, QString>> Map::queryRenderedFeatureProperties(
    const mbgl::ScreenCoordinate& point,
    const std::vector<std::string> layerIDs,
    int buffer) {

@birkskyum
Copy link
Member

Do you have an ETA on the merging [of the drawables renderer] into the main branch?

For timeline I'll have to defer to @ntadej , who is leading the last steps and merger; now that the graphics backends are implemented and demonstrated to be wired up to QLocation / widget / Quick.

@birkskyum
Copy link
Member

@skinkie , both the quick/qtlocation and the widgets have been upgraded to the drawables renderer.

@skinkie
Copy link
Author

skinkie commented Oct 19, 2025

@skinkie , both the quick/qtlocation and the widgets have been upgraded to the drawables renderer.

What does that effectively mean in relation to this pull request?

@birkskyum
Copy link
Member

It means that I'll be necessary to rebase (potentially recreate) it. The widget now support metal/vulkan/opengl through qt rhi (map_widget) instead of only OpenGL (gl_widget).

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

Successfully merging this pull request may close these issues.

3 participants