[Discoverability]: OPERA TROPO is "hidden" away and not easily discoverable

[dbekaert]

Issue type

UI/UX

Environment

Prod (https://search.asf.alaska.edu)

Page URL or route

No response

Browser & version

No response

Operating system

No response

App version / commit SHA (if known)

No response

Steps to reproduce

https://search.asf.alaska.edu/#/?maxResults=250&dataset=OPERA-S1&resultsLoaded=true&granule=OPERA_L4_TROPO-ZENITH_20260226T180000Z_20260302T000718Z_HRES_v1.0&zoom=3.000&center=24.694,5.407&productTypes=TROPO-ZENITH

Expected behavior

The TROPO dataset is SAR agnostic and should not he hidden under the OPERA Sentinel-1 dataset.
This makes it practically impossible for users to find the data unless they have a prior knowledge on it.

It would be most appropriate to stand as its own OPERA Tropospheric dataset; moreover it should be emphasis that this data is SAR agnostic and can be used for any SAR mission.

Actual behavior

Nested under OPERA-S1 then need to filter on layers to find tropo

Console / network logs

Additional context

No response

Pre-submission checks

• I searched existing issues and didn’t find a duplicate.
• I reviewed the repository’s CONTRIBUTING guide.
• I can reproduce this in a fresh browser session (no extensions, cleared cache).
• I have included screenshots/logs or a minimal repro where possible.

[dbekaert]

@tylercchase confirm this appears now as own data-set. However currently setting it to tropo dataset shows a combination of an ECMWF and TROPO product in the filter.

example: https://search.asf.alaska.edu/#/?maxResults=250&dataset=TROPO&zoom=3.894&center=159.206,-47.036&resultsLoaded=true&granule=OPERA_L4_TROPO-ZENITH_20260301T180000Z_20260305T003050Z_HRES_v1.0

[tylercchase]

I can see how that would just shift the previous problem to a new dataset, I'll bring this up to the team and see what we can do.