Contribution ? - Creating a QoL interface widget for mission planning

Hello everyone,


I work with my school research team on medium to small scale missions (both on air, water surface and below).

During those, we found ourself frequently fighting with the user interface while placing waypoints.
That’s why we would like to propose ourself to make something like a widget to overhaul said interface.

This topic is here to preshot a bit and take your various opinions on the subject (would this be mergeable ?).
For context we would hide those ‘features’ under a checkbox (something like ‘enable advanced selection’), for it to not annoy users who already have their habits.


First and foremost, we would like to go beyond the maximum zoom level.

This need especially arise when on mobile. With smaller scale missions, our finger is almost as big as our area of study on max zoom level.

From our understanding, a pixel of the map background cannot be bigger than a pixel on the screen.
This is understandable, since upscaling would introduce approximations which are not welcome.
However, this makes using QGC on a high resolution monitor quite a PITA.

Even a very basic upscaling without any interpolation would be welcomed by more than a few.
Moreover and if needs be, nothing prevent us from having multiple interpolation algorythms that the user could select from in a setting panel.


Then, we could add the possibility of importing a custom map background

This idea is very much a concept. We still have not inquired how we would do so precisely.

We saw some occurence of that one while browsing the feature requests.
On our ends, we sometimes needs a specific area with great(er) precision.

With that, we could take our map background from another more niche API, our even from our own dataset that we got from acquisition missions.

This could be as simple as to find how the import/export from the already existing “Offline maps” feature works, and create a import procedure that would convert geotagged images to that previous format.


Finally, we would love to add some QoL changes to the waypoint edition interface

This includes a few tiny features that don’t change the program workflow.

Something like being able to select multiple waypoint at a time, either throught ctrl-clicking them or drawing a selection box, and then change all the altitude coordonates at the same time, or dragging them to translate them while keeping the overall form intact. (non exhaustive)

Again, those things would be hidden behind a checkbox somewhere in the settings.


What would the community and the core devs would think about this ?

If we did add those features, would it have a chance of being merged ? (Following the code submission guide, of course).

Thing is, we will be coding this on our end whatever the response here is, since those features arise directly from our needs (the question here is, knowing that, how can we still be useful to the project in a good open-source perspective).

For most of us, it will be our first contribution to such a project, so some guidelines are appreciated.
Again, we are just taking the temperature yet. Workflow and technical specificities will be discussed in more depth on their own topics.


Also, non-english native speaker here. So feel free to ask for anything that I would have poorly explained…


Thanks for reading !

Daily builds allow you to zoom past max zoom.

If you change the default mission altitude in Mission Start it will ask you if you want to change all waypoints to this new altitude. This doesn’t allow you to change only a specific set. But changing all of them is more common than only a specific set.

Sort of interesting but unsure how much that would ever get used. Most pattern oriented mission are created using one of the supported Patterns which already allow you to shift things around as needed. I don’t see how supporting “shifting” for random collection of waypoints solve a common problem.

Yes, import is the simpler way to get started here. And would certinaly be a very useful/requested feature. The major problem is full cross platform support for working with various file formats. Geotiff, .hgt and so forth. You can see a Pull here: Map providers step2 by tilaktilak · Pull Request #7898 · mavlink/qgroundcontrol · GitHub which was never finished unfortunately.