VESPA telecons & meetings

Action items:

Actions items:

See with ESA how datasets in ESA-GSF (PSA's grey area) can be installed as EPN-TAP services - right time to start this
See how limits of geologic (Mars) or morphologic units (67P) can be provided as an EPN-TAP service
Stéphane Erard : sent new awstats script to every provider for installation (available on ObsParis gitlab)

Actions items:

Stéphane Erard Install 2 service files from 2019 (Rome) workshop on Paris gitlab
Gitlab usage to be assessed in Heidelberg and Trieste - see here :Individual Repository for VESPA Service Resource Descriptor in DaCHS and VESPA hubs
Gitlabs to be used for coming implementation workshops (in real time, so that everybody can work in a familiar environment)
Decide upon nb of Gitlab servers (1, 2 or 3?) and interactions between them - may be better to have only one.
Use gitlab issues to report and follow problems in services (must be open to all VESPA participants)
All 3 teams will help resurrect dying services - need a way to give them visibility for this
AAI to be evaluated later - must not affect existing systems

Actions items:

ID required for coordinate frames (again!) - not in MOC though
OK in an EPN-TAP table on use case. Solves the direction issue of s_region.
We need to keep the possibility to have different spatial_coordinate_description values in a service (ex: spectro_planets, draft upgrade)
=> spatial_coordinate_description must be included in ADQL queries involving regions or coordinates
Could be accommodated either in s_region or in a different parameter (preferred)
(s_region is currently expected only as polygon, and for body fixed frames)
(s_region polygons are probably mandatory for use with QGIS)
Study use of hips progenitors (e.g. mosaics of surface images)
Assess usage of time-space MOCs for space experiment operations (possible use with VVEx, etc)

Actions items:

Need to start thinking about the future service for NA2 / telescopic obs
Where will it be hosted?
- I've always assumed Graz, TBC
- Ricardo proposes to split among existing services - but this is probably not feasible, and not actually simpler
- may be located on VESPA-cloud in the mid-term (so that several teams have complete access)
- First runs/data: not before October
Design?
- Must start as a simple demo for images & spectra; EPN-TAP parameters ~ PVOL-like. Start discussing this with teams involved (NA2)
- Assume data will be forwarded to the service by NA2 team, so no upload interface involved
- Ingestion is easy if fits files with complete headers - may be complicated otherwise. Correct timing is crucial
About PVOL itself:
- Additional content will include JunoCam images, planetary spectra, projected images
- PVOL is a typical example of service which needs support on sustainability
- Same comment as above about VESPA-cloud (EPN-TAP service files only)
- We need to have the EPN-TAP service files (q.rd, etc) stored on a gitlab for sustainability - can it be the one in Paris (already active)?
- In a first step, that would allow other teams to give a hand modernizing the service (e.g. adding epheremis calls should be easy, as HST or spectro_planets)
- MOCs may prove useful to provide a view of space-time coverages, and comparison with e.g. HST data

Large room for collaborations, including:

LMD and exoplanets GCM
GEOPS and surface boundary conditions (topo)
LESIA for disks db (and also exoplanets DM)
Maybe a link with UCL simulations?
Design EPN-TAP extension for these simulations
Thematic section in Confluence: VA-Task 2. sub-task Exoplanets
Possible installation on OPUS platform for code-on-line (to come, eventually on EOSC)?
Any link with DACE? They've developed efficient python APIs, and are willing to collaborate and go VO
Try and develop collaborations with ExoplANETS_A H2020 prg (which includes UCL)

Next visioconf: date & object TBD, some time in September (related to EPSC sessions?)

Page tree