Meeting Notes

2022-11-07

Gregory Dubois-Felsmann , Andy Salnikov , Tim Jenness 

• Andy has a working prototype
• Intended for use with /repo/embargo on USDF, which is currently set up to receive newly acquired LATISS data (confirmed by KTL today)
• Based on a pgsphere installation on a test server
• Waiting for USDF deployment of pgsphere 1.2 on production server
• Real frustration with lack of clarity on pgsphere versions and appropriate sources
  • General community agreement, apparently, that postgrespro/pgsphere is the focus of recent development
    • Repo has no releases and not even any tags
    • No release notes either
    • Commit messages suggest that the repo may contain a version 1.1.4 and a version 1.2/1.2.0
  • Apparently defunct sites/repos:
    • https://pgsphere.github.io/ (not obviously updated since 2017)
    • GitHub pgsphere/pgsphere (main not updated since 2019, nothing significant since 2017, stale PR from 2020)
    • GitHub akorotkov/pgsphere (main not updated since 2019, nothing significant since 2017, but 8 open PRs including 5 from 2022)
  • Well-known Postgres community repositories of installer packages have nothing newer than 1.1.1 (from 2010)
    • https://www.postgresql.org/ftp/projects/pgFoundry/pgsphere/pgsphere/
    • However, see: https://www.postgresql.org/message-id/E1kMt08-0003zz-Ur%40atalia.postgresql.org for a sign of life in 2020
  • Gregory will follow up with others in the IVOA community about tagging/releasing
• Andy needs an appropriate configuration for use with LATISS data
  • Gregory can take a look at Andy's current starting point while we're waiting for the production installation of pgsphere
• Gregory asks if the dax_obscore system still also retains the capability to do static exports of ObsCore data, as we did for DP0.2
  • Andy: yes.  Some appropriate parts of the code are shared between the "static" and "live" implementations.  Static exports do not use pgsphere-style geometry, though.
  • Gregory: would like to run another static export on DP0.2 sometime in the next month or so in order to fine-tune the presentation
• How to get a TAP (ObsTAP) service in front of /repo/embargo in one of the USDF RSP instances
  • Probably should be at a dedicated endpoint for now
  • Gregory will talk to Frossie about whether SQuaRE can assist with a TAP deployment based on Christine's experimental /api/obstap from the IDF (based on static data about WISE images)
  • Gregory worried that the forked state of phalanx usage in the USDF will add friction to this effort

 Actions

• Gregory Dubois-Felsmann will talk to Pat Dowler and Markus Demleitner about how to move forward with tagging at postgrespro/pgsphere, if not actual binary package creation 11 Nov 2022 
• Gregory Dubois-Felsmann will talk to Frossie Economou about how to get a prototypeObsTAP service deployed on USDF
• Andy Salnikov will point Gregory at a configuration to review in the near future 09 Nov 2022 

Followups

• Gregory Dubois-Felsmann filed https://github.com/postgrespro/pgsphere/issues/9 to try to explore the sense of the community around pgsphere

Background

The "Live ObsCore" project is an attempt to solve the problem of how to provide image query services in RSP instances used for commissioning, and in other instances where the available data are regularly changing.  The idea is to enable the creation of a table, which would normally be named "ivoa.ObsCore", based on the continuously updating contents of the Butler registry tables in the database.  Early R&D indicated that this would not be feasible to do as a view, so a more complex piece of software, integrated with the Butler to some extent, was required to deliver the capability.  Since the Butler database is generally Postgres-based for all but the most lightweight installations, it is natural to have the ObsCore table in Postgres as well, and to access it via CADC's TAP service, which includes an implementation for a Postgres backend with the pgsphere geometry extension.

JIRA queries