The current layout results from many interactions and user feedback during EPN-2020.
• A general assessment of usability will be conducted by SpaceFrog Design, based on User Experience analysis (see VESPA UX/UI).
Main evolution to support future EPN-TAP versions
- Reorganize query panels: add access_format to main panel (search with LIKE)
- Reorganize query panels: add service_title to Data Reference panel (search with LIKE?)
- Also add file_name? (not always there, but same kind of request as granule_uid)
- Implement all mandatory parameters in standard query mode panel
- Update value lists for parameters: in particular "none" for spatial_frame_type
- Need to implement all common optional parameters in the "optional" panel - long standing issues, and a blocking one
- The standard mode should detect EPN-TAP version of service, to handle both EPN-TAP 2.0 and 2.1 (when 2.1 is ready…)
- Check with complete spoly in s_region (beware this is printed as STC-S after an ADQL query and in the output VOtable) see if INTERSECTS works - urgent (the new sandbox DaCHS supports it…). Check if there is an issue with longitude convention and s_region
- If needed, check if sPoly can be generated on the fly from STC-S string in s_region (see simpleSTCSToPolygon function in module tapstc)
- Implement spatial queries as in support.epntap ticket 31/5/2016 (with INTERSECTS, CONTAINS… + other modes, check that ticket).
2019: the full query is more complicated - it requires to upload a table on a data server, so it has to go through TOPCAT. Basic INTERSECTS, etc (on a single region)… may go through the portal, but the Coord Syst should be checked in the same query.
- Fix queries on string parameters: always use LIKE instead of =, use lower() on both arguments: where lower(instrument_name) like lower('%CIRS%') ; or provide options
Case support still to be implemented on processing_level, dataproduct_type, + target_class - ??
Add a list of measurement_type values present in connected services (but allow for other values in the query)
- do this also for instrument_name & instrument_host_name?
On alt_target_name, bib_reference, it would be better to use a combination of hashlist and LIKE. Start with a simple LIKE for the time being.
Implement searches with LIKE (instead of =) for all other string parameters
- On first and next pages: the list of tools is sometimes understood as the complete list of tools connected to VESPA - we have to fix this.
Plus, some people want a short indication of what these tools are for… (maybe we can add a link to a special help page, or a help bubble, under the subtitle "Plotting tools"?)
Plus-plus, links to VO support services would be nice (ssodnet, Miriade, Spanish filter service… )
- We need a function to retrieve all parameters used in declared services (with indication of service where they appear). In some case, existing values may be also required, TBC (this is more a review tool than interface related). Test service in 2018, not finalized (unexpected issue with ?)
- Need to reflect changes in EPN-TAP v2 PR version (21/7/2021) - in particular value lists
Additional functions on Query form