Skip to content

Conversation

@haticekaratay
Copy link
Contributor

@haticekaratay haticekaratay commented Sep 18, 2025

Description

This pull request:

  • Introduces a new skewer selection tool.
  • When a user clicks in the viewer, the tool checks if the click falls inside any footprint.
  • If multiple footprints overlap at the click point, it chooses the footprint with the smallest polygon area.

Fixes #

Change log entry

  • Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
    list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
    should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

  • Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
  • Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
  • Do the proposed changes follow the STScI Style Guides?
  • Are tests added/updated as required? If so, do they follow the STScI Style Guides?
  • Are docs added/updated as required? If so, do they follow the STScI Style Guides?
  • If new remote data is added that uses MAST, is the URI added to the cache-download.yml workflow?
  • Did the CI pass? If not, are the failures related?
  • Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
  • After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

@github-actions github-actions bot added imviz plugin Label for plugins common to multiple configurations labels Sep 18, 2025
@haticekaratay haticekaratay added this to the 4.4 milestone Sep 18, 2025
@rosteen rosteen modified the milestones: 4.4, 4.5 Sep 18, 2025
Copy link
Member

@kecnry kecnry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its good to see movement again on footprints, thanks! 🎉

pyproject.toml Outdated
"pyvo>=1.5.3",
"s3fs>=2024.10.0"
"s3fs>=2024.10.0",
"spherical-geometry"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're trying to be very intentional about adding additional dependencies, although this one seems to be maintained internally and pretty lightweight. Do we need any specific version?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need a specific version, at the moment. We're also cautious about adding deps, but implementing our own spherical-geometry in jdaviz would be strange.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is very similar to our current catalog_select icon. Is this just a placeholder for a custom icon or should we plan out how to differentiate between these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! That’s a placeholder at the moment. I’m getting Jenn’s input on the right icon for this new tool.



@viewer_tool
class SkewerSelectFootprint(CheckableTool, HubListener):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of a separate tool, was a modification of the current tool considered (ctrl+click, keypress event, etc) considered?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s a good point. For this case, we wanted it to be a separate tool. The interaction is different enough (skewer vs. nearest footprint) that we thought it would be clearer for users to have its own tool. cc: @bmorris3

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the interest of maximizing discoverability, is it possible to have the tool menu show a selection icon with an expand arrow, which opens a submenu of footprint selection options?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we already have the dropdowns in the toolbar, I'm not sure we want another level of nesting... but maybe we need somewhere for tool settings?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another take: should there be a new 'selection options' tool, with a mouse arrow icon, that expands with the selection options? I don't think these choices naturally belong in a group with blinking and contrast/bias.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could split that "category" into two, but that increases the probability of horizontal overflow issues (which are not currently handled well) for narrow viewers. We also had a long-term plan (not currently prioritized, afaik) to allow activating viewer tools from the plugins themselves which I think would really help in this case as the footprint plugin could then put the tools in more context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, adding this as a separate group doesn’t feel like it adds too much clutter, but I agree the bigger issue is that the jdaviz toolbar isn’t really responsive right now. Maybe we can treat that as a follow-up improvement, while in the meantime this gives users clearer control.

image


def _handle_skewer_click(self, data):
"""Spherical (great-circle) selection: only selects if the click is INSIDE a footprint.
If multiple overlays contain the click, picks the one with smallest area.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this should also be in the tooltip? I was wondering whether it would select multiple, closest, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The longer-term goal is to select all matches, once footprint multiselect is compatible with the Footprints plugin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, depending on the resolution of the conversation related to that... if this stays with the single-select at least for now, it might still make sense to describe in the tool description/tooltip and we can always modify that once multiselect is included.

Copy link
Contributor

@bmorris3 bmorris3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following comment applies to the implementation as it is written, where multiselection isn't an option. I'd argue that we can't have true skewer selection without multiselection.

While testing, I think I noticed a bug when the footprint has multiple marks. In this video, I'm alternately clicking on 1) the overlap between the green MIRI footprint, the magenta FGS footprint, and the orange NIRSpec footprint, and 2) the overlap between the green MIRI footprint, the magenta FGS footprint.

smallest-area.mov

For click (2), the skewer selection tool is choosing the smallest area mark, which is the green MIRI footprint (✅).

For (1), skewer select appears to choose the mark with the smallest area. The smallest mark which contains the click coordinate is determined to be NIRSpec, even though NIRSpec has the biggest FOV of all the choices here. Is it picking NIRSpec because it's comparing the mark area, which is ~1/4 of the full FOV?

@kecnry – what's the least disruptive way to implement footprint multiselect?

@kecnry
Copy link
Member

kecnry commented Sep 24, 2025

what's the least disruptive way to implement footprint multiselect?

I think we had discussed this a while back, but can't remember the details. What functionality do you want to support with multiselect? I think the closest analog would be the implementation for subsets in subset tools - in multiselect mode the user is no longer allowed to view/edit the properties of the subset and only see actions that can be completed in bulk (currently recentering).

@haticekaratay
Copy link
Contributor Author

While testing, I think I noticed a bug when the footprint has multiple marks. In this video, I'm alternately clicking on 1) the overlap between the green MIRI footprint, the magenta FGS footprint, and the orange NIRSpec footprint, and 2) the overlap between the green MIRI footprint, the magenta FGS footprint.

Yes, that’s the behavior I implemented. The selection logic doesn’t look at the full FOV of the instrument, but instead compares the area of the specific mark polygons at the click location. So in your example, it’s picking NIRSpec because that individual polygon has the smallest area among those containing the click, even though the full FOV is larger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

imviz plugin Label for plugins common to multiple configurations

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants