Add pipeline option groups and enhance EditPresetDialog UI

[thadwald]

This enhancement is my effort to organize the array of processing options in WebODM. The intent is to achieve the the following:

• Group options by the underlying technology that they target
• Order groups by the sequence in which they are used in the ODM pipeline

This makes each feature easier to find. More importantly, it communicates the pipeline order and how each option fits into this order. This should help to flatten the learning curve for the tool.

I also included a search feature to aid in quickly finding an option, as well as an option for reverting to the traditional A-Z flat view.

Screen shots:

[Data-Delivered]

Love this idea and your implementation!

[Saijin-Naib]

This looks phenomenal and helps lower the first-start barrier for sure.

Is it still able to be screenread and navigated by keyboard (tabbing, etc)?

[thadwald]

Keyboard navigation is consistent with the original implementation; tab stops on the text boxes but not on the checkboxes. This is not correct but it is unrelated to the changes I introduced.

[pierotofy]

Thanks @thadwald! Looks like it could be a good improvement for making the options list more readable. Did you use LLMs / code agents to write this?

[thadwald]

I made a slight change to the group names and icons.

@pierotofy I used Claude.ai.

[pierotofy]

This should be tested with NodeMicMac (which has different options that NodeODM) and Lightning (which uses LGT and does not have the same number of options as NodeODM). Also, I'm worried about the use of some esoteric CSS and JS functions that claude picked that might not work in all browsers, so this needs manual testing (have you tested mobile and desktop browsers?)

Most importantly, and I knew this would happen, here we are, with a useful contribution that people want, but by dubious self-imposed rules I cannot merge it. OpenDroneMap/documents#3

@smathermather @Saijin-Naib

[thadwald]

It's a valid concern.

Yes, it's doggedly persistent in creating buggy code, but It's also a great tool for spotting bugs and typos. For the record, all of my submissions to the Open Drone Map project have involved IA. Some are simple, others aren't.

My suggestion (for what it's worth) is to not ban it outright, but to vet every single line.

And in the case that you cannot reconcile the use of AI at all, here's a great idea for future development of WebODM!

If you look closely, you'll see handling of options not in NodeODM, that I added to my local NodeODM. So it handles missing options well.

:

[pierotofy]

OpenDroneMap/documents#4

[pierotofy]

I've made some changes to address a few things with this PR:

• Re-arranged some groups and subgroups; I've found several items out-of-place and a few mispellings.
• Fixed scrollbars and incorrect CSS
• Fixed problems with alignments
• Single collapse/expand button
• Icon consistency with other parts of the UI
• Fixed a bug caused the improper conditional rendering of NodeOption components which would make unexpanded options to disappear from selection (really bad).

I've found no infringements of copyright in the code after refactoring and analysis.

Thanks @thadwald

[pierotofy]

TODO before merging:

• Update locales / strings
• Review one more time
• Mobile testing

[thadwald]

@pierotofy Your feedback is duly noted. I'm glad that the idea is finding its way into the project.

[thadwald]

I would also change the default state to collapsed--if you haven't already done that.

[smathermather]

I'm glad that the idea is finding its way into the project.

Thanks for this and the ongoing monitoring of the thread. I have proposed that as an alternative to merging against our policy, that we conduct a bit of a test case for integrating changes like this into the code base:

• Similar to API or IBM PC cloning, we summarize the changes;
• Separately, we task someone with implementing that summary of changes.

In this way, we take advantage of the thoughtful work you put into vision and prompting, without the other challenges associated with prompt engineering.

---

If reasonable, would you be willing / able to put together a summary of the changes in this pull request for re-implementation?

[pierotofy]

I would also change the default state to collapsed--if you haven't already done that.

Yep, that was one of the changes I've made.

[pierotofy]

we task someone with implementing that summary of changes.

I'm going to finish / merge this work (which includes a lot of my changes, sans-AI) today, if/when another implementation becomes available from someone we can always git revert and swap.

[thadwald]

If reasonable, would you be willing / able to put together a summary of the changes in this pull request for re-implementation?

... to go ahead with the test case idea:

In a quick summary, these changes involve hard-coding a logical grouping of ODM options in the webodm ui component. Would this be enough?
I could also copy-paste the summary of execution that Claude always provides at the end of a job, which might be a bit ironic, in a way.

My instinct was to describe these groups alongside the options in ODM itself. I decided to add them here instead because it's a bit easier to implement and more importantly (to me), I am doing this work inside a docker container and it was impossible for the AI tool to access the ODM container....

Was this the correct decision?

On another note, I caught and fixed the issue with collapsed items not working, and also fixed the mismatched theme elements and icons. I was just not motivated to copy the changes here because it appeared that the code wasn't going to be used anyway. My apologies for abandoning it like that.

[pierotofy]

Was this the correct decision?

Yes. Adding them in ODM would have complicated the NodeODM API.

[pierotofy]

My apologies for abandoning it like that.

No need; I want to apologize for the length it took to make progress with this contribution.

[smathermather]

In a quick summary, these changes involve hard-coding a logical grouping of ODM options in the webodm ui component. Would this be enough?

Perfect.

I could also copy-paste the summary of execution that Claude always provides at the end of a job, which might be a bit ironic, in a way.

Ha! It would be. I cannot see that that would violate our policy, and it would be interesting to see. That might be a good thing for us to ask for in future similar pull requests.

I was just not motivated to copy the changes here because it appeared that the code wasn't going to be used anyway. My apologies for abandoning it like that.

Perfectly understandable. This particular feature addresses IMO one of the longest running feature requests for WebODM -- taming all the options! Really glad you stuck with us while we sort through project governance in this new age.

This is, as far as I know, among the first substantive pull requests we've gotten that is prompt driven. My aim is to be quicker in getting someone in to re-write these kind of high value concepts, so thanks for being patient as our test case.

Expect to see this re-written to match policy shortly. I'll share a timeline here as soon as I know it.

[thadwald]

Would it make sense to move pc-classify and pc-rectify to the Digital Elevation Models group?

[pierotofy]

They affect the point cloud output, so I think their current location is OK.

[smathermather]

Expect to see this re-written to match policy shortly. I'll share a timeline here as soon as I know it.

Quicker than expected. Expect a pull request with a replication of the functionality early this week.