Versions Compared

Key

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

...

  • EPN-TAP is a VO access protocol dedicated to Planetary Science data. It is based on the TAP mechanism from IVOA, completed with sets of parameters and associated lists of values. In this regard, it is similar to ObsTAP but with a different scope.
  • EPN-TAP was described in its first version in Erard et al, Astronomy and Computing 7 p.52-61 (2014). Version 1 was designed as part of the IDIS activity in Europlanet-RI (FP7).
  • EPN-TAP version 2 is a major update of the protocol to accommodate larger services and simplify setup and use of data services. All parameters are described here.

...

  • The "laundry list" format makes services easier to design and to query
  • Allows grouping of results from several services at once
  • Supports multispacecraft observations
  • Speeds up mirroring of services (support for partial updates)
  • Better support of footprints, and better interface with GIS

 

Main

...

evolutions relative to v1

1) The previous notion of dataset is deprecated

...

A granule is still a record/line in the epn_core view database, and corresponds to the smallest data unit described by the service.
A "product" is typically a data file, or a service output, that can be reached through a URL
In version 2 both concepts coincide, while in v1 the same a single granule could be composed of several products related to the same initial data (an "observation" in v2)

 

In EPN-TAP v2, granules are referenced by 3 parameters:

  • granule_uid provides a unique ID for the granule in the service, ie for each line in the epn_core view. It is equivalent to the previous index parameter (index is a reserved word in many database languages and should not have been used in the first place)
  • granule_gid is related to a type of product: it is identical for all granules containing the same type of information for different observations (e.g., calibrated files). An explicit string is recommanded recommended in this field, with suggested standard values (e.g., preview/native/calibrated/geometry/projection…).
  • obs_id is related to an observation: it is identical for all granules related to the same observation, containing different type of data (e.g.: raw and calibrated data, associated geometry, etc). In many EPN-TAP v1 services, such products were described together on the same line with a unique index parameter.

...

3) The notion of table/service parameters is deprecated

Such parameters were available in the registry only, and were not directly accessible by TAP. In v2, constant parameters must be replicated in every line of the epn_core view.
Such parameters may be duplicated in the registry declaration though, so as to provide a fast description of services.

...

s_region is a parameter in the ObsCore standard of IVOA, and ADQL allows for powerful query functions such as intersections or inclusions. s_region introduces a pgSphere variable of type spoly providing description of the observed area on a sphere, which allows for accurate searches.

This can be used to provide footprint footprints of spatially extended data either on the sky or on a planetary surface (as long as it is reasonably ellipsoidal).
Use with 3D shape models needs study (
should this may fail with concave 3D shapes such as 67P). Also need to study how concave footprints/polygons are handled, TBC. The use in the context of GIS also has to be studied.

The C1/C2 min/max parameters can still be used to provide a bounding box of the observation.

 

5) Better support of evolving services

...

These parameters must be provided as ISO 8601 strings with format "2013-11-17T10:41:00.00+01:00" (with no space) where the indication of time zone is mandatory. The associated data type must be "date". ADQL supports this format, and filtering using based on time zone is possible.

 

6) Support of coordinated observations

...

All parameters defining a range are now introduced with a min and max value.
All floating point parameters are now in double precision to prevent errors.

...

are now clearly identified - those are not only mandatory, they also must provide a value.
They are mostly related to service description and granule identification. 

 

+ See notes below the table.

...