-
-
Notifications
You must be signed in to change notification settings - Fork 37
Add support for queryRenderedFeatures in Qt interface #222
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
base: main
Are you sure you want to change the base?
Conversation
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.
for more information, see https://pre-commit.ci
|
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. |
|
Do you have an ETA on the merging into the main branch? |
|
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) { |
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. |
|
@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? |
|
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). |
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.