Meeting notes: 2025‐05‐13 - spacetelescope/mast-aladin-lite GitHub Wiki

Meeting: Aladin Lite and Roman Research Nexus

(formerly known as Roman Science Platform)

May 13 2025 / 9:00 AM EDT

Agenda

  • Introductions

  • Quick overview of our Roman Science Platform project, current plans and investigations

  • Catalog object and footprint selection (we can provide more written thoughts on possible approaches prior to meeting)

  • Other technical questions/thoughts (time permitting)

  • Next steps

    • Was this meeting worthwhile? Should we do another one?
    • Other actions
    • Would a longer virtual hack session be worthwhile?

Attendees

  • STScI: Brian, Patrick, Tom, Scott, Hatice, Brett, Celia, Fabio
  • Matthieu, Thomas, Manon

Notes

Quick overview of our Roman Science Platform project, current plans and investigations

  • Roman Research Nexus (formerly known as the Roman Science Platform) is a STScI owned/managed JupyterHub running on AWS. Provides users data access for Roman observations, which will be hosted on S3.
  • One visualization tool developed at STScI has JWST- and Roman-specific features, called jdaviz: https://github.com/spacetelescope/jdaviz/
    • preliminary ipyaladin integration with jdaviz is shown in this recorded demo: https://stsci.box.com/v/cobalt-q2-imviz-aladin-demo
      • Manon: users have requested a feature for matching rotation for multiple ipyaladin instances. This is planned, not expected to be done before October

Catalog object and footprint selection

  • STScI folks have collected notes to guide catalog/footprint discussions on github: https://github.com/spacetelescope/mast-aladin-lite/blob/main/docs/discussion/selection-api.md
    • what we have figured out with ipyaladin so far: we can select catalog objects within an astropy Region object, we can keep track of regions that have been selected
    • can't make selections for ipyaladin instances that have scrolled offscreen
      • Manon: ipyaladin may not return a wcs attribute when the widget is scrolled offscreen because jupyterlab optimizes widgets rendered in notebooks that are shown offscreen. there's a jupyterlab GH issue open related to this: https://github.com/jupyterlab/jupyterlab/issues/16630. The behavior can already be switched off (see ipyaladin documentation).
  • Tom: it would be helpful to provide catalog object selections with indices or unique values
    • Manon: maybe the selectSources method should take a list of booleans to specify selected/unselected catalog objects + name of the catalog in Aladin Lite : opened an issue in A-L to support this (https://github.com/cds-astro/aladin-lite/issues/296))
    • Patrick demos catalog object selection with a proof of concept attr: aladin.select_table(table, **keys=["column_name"]**), which selects any objects in table that have matching values in the catalog's column named column_name
  • Tom: region selection – astropy Regions are not exactly the intended regions on the sky that they claim to be, in general. line segments between vertices are "straight lines", not great circles
    • Thomas + Manon: currently, selections are defined in screen coordinates, because interactively drawn selections are drawn in screen coordinates. But when you add a region via API, it should be drawn as defined on the sky, not using screen coordinates.
    • Thomas: we plan to implement an API method for skewer selection
    • Manon: in the Cobalt API proposal on GH you suggested get_selection, but this already exists under a different name in ipyaladin. the other two features don't exist yet (and they would be welcome additions)
    • Tom: suggestion to incorporate masking as a part of selection, would involve further work and thought to avoid confusion in API with dual functionality
  • Region(/footprint) selection:
    • aladin-lite uses STC-S regions because it uses obscore which produces s_regions
    • Tom: recognized that with an s_region, there is also probably a coordinate (RA/Dec pair). Should the coord be displayed along with the footprint? There are use cases for both, but maybe it should be optional. (CDS agrees)
  • Manon: we suggest not using MOCs for regions. You can always turn a MOC into STC-S, but that translation is lossy, so you can't turn an STC-S into a MOC.
    • Thomas: if a user wants to select objects with a MOC, should we do this in python or aladin-lite?
      • Manon: it's better in Aladin-Lite but the feature already exists in MOCpy to do this in python.
  • plans for future meetings:
  • Thomas: we'll plan work on footprint selection. that's the difficult part because there are *many *options. for ipyaladin that will be harder in the coming months. likely be done in the next two weeks, or in September.

Things to follow up on:

  • will aladin-lite support circle/cone search for footprint selection?