Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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