VESPA kick-off telecon
- 4 years to go!
GMAP & VESPA interactions telecon
- 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)
First VESPA hubs chat
- 15 May 2020 (Stéphane & Markus)
- 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
MOC versus s_region for EPN-TAP services
- 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)
PVOL, NA2 & amateur services
- 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
- 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
Next visioconf: date & object TBD, some time in September (related to EPSC sessions?)