Improve UX of the mission planning pipeline

[ArturoManzoli]

New Features List:

• Added a context menu for mission planning creation and editing processes.
• Survey polygons can now be relocated by dragging them on the map.
• Surveys can be individually deleted.
• Users can select the angle at which the survey will be scanned.
• The scanning angle can also be edited after the survey is completed.
• Last survey can now be edited back to the polygon level, allowing users to adjust the distance between scan lines (scan density) and the scanning angle
• It is now possible to concatenate multiple surveys or simple paths to form a complex mission around a complex map scene

Screenshare.-.2024-11-26.4_37_36.PM.mp4

Screenshare.-.2024-11-26.5_44_58.PM.mp4

closes #1355
closes #1350

[rafaellehmkuhl]

@ArturoManzoli since the two first commits are unrelated to the mission planning part, could you open dedicated PRs for them? This way we can test them separately and merge sooner. This will also make the review and rebase processes easier.

[rafaellehmkuhl]

Nice improvements!

I will add some points from my usage tests here.

1. Could we make the survey path follow the angle change live, as it was before? It helps specially with surveys with concavities where the user needs to know if the change in the survey angle will make it go outside the survey polygon.

Kapture.2024-12-05.at.06.12.11.mp4

2. The survey angle change step should be 0.1 degrees. It's currently not limited.

3. I cannot select the regular mission path waypoints to see them, and so I cannot see information around them.

Kapture.2024-12-05.at.06.15.19.mp4

4. If I have more than one survey, I cannot edit them. Is this expected? Once I removed one of them, I could edit the other again.

Kapture.2024-12-05.at.06.17.43.mp4

5. "Scan density" should be renamed to something like "Scan spacing (m)", as the density is actually decreasing as the number increases.

6. I couldn't find the button to delete all waypoints. Where is it?

7. About Allow user to specify the angle of attack for a survey mission #1350, is this PR changing something on the logic related to the survey angle?

Will take a better look at the code and put notes at a separate review.

[julled]

Very nice new features! looking forward to get them integrated!

[ArturoManzoli]

1. Could we make the survey path follow the angle change live, as it was before? It helps specially with surveys with concavities where the user needs to know if the change in the survey angle will make it go outside the survey polygon.

Didn't get what you mean here. Are you referring to the dashed lines that preview the survey scan path? Because they do update live.

2. Done

3. This is almost done. Its coming on the next mission-planning related PR. Check it out:
   https://github.com/user-attachments/assets/e1aff670-3eee-43ea-b50a-6e335720925c

4. Yes it is a known limitation that the current Undo process has. It will be addressed on a near future improvement task.

5. Done

6. I couldn't find the button to delete all waypoints. Where is it?

Oops, its added now:

7. About Allow user to specify the angle of attack for a survey mission #1350, is this PR changing something on the logic related to the survey angle?

Yes, it did implement the feature of selecting and changing the 'angle of attack' for a survey. Although, we did decided later on to not call it 'angle of attack' because of the existing aeronautical term.

[rafaellehmkuhl]

1. Could we make the survey path follow the angle change live, as it was before? It helps specially with surveys with concavities where the user needs to know if the change in the survey angle will make it go outside the survey polygon.

Didn't get what you mean here. Are you referring to the dashed lines that preview the survey scan path? Because they do update live.

As discussed on a meeting, the idea here is to the path angle to change live while the user is dragging the arrow, instead of needing to release and press it repeatedly to archive the desired path.

[rafaellehmkuhl]

Some thoughts around the code:

1. This PR has around 8 big changes. It is important to separate those into several commits during development. It is really hard to review one big commit with 2 thousand lines, and it's also difficult to make sure nothing is broken during the review process, as all changes are made to the same commit.

2. When moving a file that is also being modified in the same commit, we lose the diff completely. This is what is happening with the MissionPlanningView.vue file. There's no way for those reviewing the code to understand what is being changed. This is specially a problem here where the file had 700 lines added. My suggestion is that this file remains where it was, as it is the base view file, and move the ContextMenu.vue and ScanDirectionDial.vue to a subfolder in the src/components folder instead.

3. The provide/inject functionality was added in Vue to make it easier to deal with with prop drilling. This is not the case here, since the ContextMenu is a direct child of MissionPlanningView. We should use props and events instead.

[rafaellehmkuhl]

There's something going on with the PR. I just checked-out the last branch update and it shows the old interface:

[ArturoManzoli]

There's something going on with the PR. I just checked-out the last branch update and it shows the old interface:

Yep, the context menu already had the correct text. Changing the button to match it

[ArturoManzoli]

On the last push:

• Converted the provide-inject to an emit method;

[rafaellehmkuhl]

It seems there's a problem with the commits:

• The first commit has the title "Mission-planning: Add context-menu component", but it is actually adding the entire functionality of the PR
• The second commit says it's going to "Add scan direction modifier to existent surveys", but it end ups rewriting a lot of functionality from the first commit, and also implementing functionality from commits 3 and 4.
• Commit 3 says it's adding the undo functionality but is actually disabling dragging, which is them re-enabled in the last commit.

I think a good separation, that would make your life easier, is to have the first commit only creating the ScanDirectionDial component, and the second commit only creating the ContextMenu component (literally only adding the components files, since they didn't exist yet, but not importing those components anywhere, to not complicate things), and leave the importing/implementation of the functionalities to subsequent commits. This way I think you shouldn't have problems with the rebase process.

[rafaellehmkuhl]

Ok, I see now that what is happening is that you added the functionality in the first commit to remove it later in this one. This should be fixed. I will put a suggestion in the review comment.

[ArturoManzoli]

Yep, thanks for letting me know. I'll restructure the commits. They were tidy until last rebase. I'll check what happened