Versions Compared


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


In version 2 both concepts coincide, while in v1 the same granule could be composed of several products related to the same initial data (an "observation")


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 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.

All such IDs These 3 parameters can be arbitrary alphanumeric strings .See see example application to APIS service below.


As a general ruleIn practice, different products related to the same observation are no longer described together on a single line of the epn_core view, but on successive lines associated by the same obs_id, each with a different granule_gid (and a specific granule_uid, see Table 2 below).

Each line in the epn_core view must describe only one product (plus a thumbnail wherever relevant). The notion of "main product" (which was more or less explicit in v1) is therefore deprecated, and the epn_core view in v2 includes more lines than in v1. Although less compact that the previous table presentation, this list presentation is much more efficient for machine-handling, and easier to design.


3) The notion of table/service parameters is deprecated


The corresponding parameters may be present also duplicated in the registry declaration though, to provide a fast description of services.


From our first discussions, the best option may be to use an ISO 8601 string with format "2013-11-17T10:41:00.00+01:00" (we don't want any space in the string) — TBC with ADQL capacities, in particular the support of time zones.