Topic of the month: spatial coordinates

Please comment - the outcome of the discussion will be integrated in this page.

Blue parts need comments in particular

Spatial Coordinates (c1, c2, c3)

These parameters provide up to three spatial coordinates on the measured target.

Spatial coordinates can be provided in the epn_core view in several systems types, as defined by the spatial_frame_type parameter. In order to make uniform requests possible however, spatial coordinates are standardized for each type of frame. If the native coordinate system used with the data follows different conventions, the (c1,c2,c3) coordinates must be converted to the standard EPN-TAP conventions below (e.g., body-fixed coordinates with westward longitudes must be converted to eastward longitudes in the epn_core view). No conversion is expected during queries.

All services must handle three spatial coordinates, even when the third one is always set to NULL. All coordinates are related to the observed area in the current frame; in particular c3 is expected to provide an altitude in body-fixed frames, while the target-observer distance (e. g., geocentric distance for ground based observations, or spacecraft distance) is introduced by the optional parameter "target_distance".

Secondary coordinates can be introduced using additional axes, e.g., c1 and c2 providing central longitude and latitude of a planetary disk in a celestial image, and optional RA / Dec parameters providing the location on the sky at this moment.

The native coordinate system (used in the data files) can be described by the spatial_coordinate_description and spatial_origin parameters. This is intended to provide this information as easily as possible to mapping tools; different granules may use different coordinate systems in the same service. Descriptions for EPN-TAP are provided in [RD17].

spatial_resolution

These parameters provide a simple estimate of resolution, either the FWHM of the PFS on the sky (in degrees), or the pixel size on a surface (must be the same units as coordinates), depending on spatial_frame_type. 
The client front-end may propose more appropriate units to the user, depending on context (e.g., angular resolution in mas, distance in m…).

spatial_frame_type

Provides the "flavor" of the coordinate system, which defines the nature of the spatial coordinates (c1,c2,c3) in the epn_core view and queries, and the way they are defined. This parameter must be informed whenever spatial coordinate are provided in the epn_core view (they cannot be interpreted otherwise). If the coordinate system associated to / included in the data themselves is different, the epn_core view coordinates need to be converted. The possible frame types are described below:


celestial (= equatorial heliocentric): 2D angles on the sky: right ascension c1 and declination c2 + possibly heliocentric distance in c3. Although this is a special case of spherical frame, the order is specific. Earth distance may be provided as target_distance whenever relevant (ground-based observations). RA ranges from 0 to 23.599. Do we need to set an epoch (equator of date…)?

- is there a need for an horizontal (alt-az) frame? Doubtful for data, may be required to handle the observatory list.


body (= body-fixed - this is actually planetodetic, right?): 2D angles on a rotating body: longitude c1 and latitude c2 + possibly altitude (above a standard reference surface for this body) as c3. 
In body fixed frame, coordinates C1-C2-C3 depends on the coordinate system defined in Spatial_coordinate_description, but they must honor some constraints: eastward longitudes in C1, N pole defined according to IAU 2000 rules for small bodies, C3 provided in km above the standard reference surface for this body.
Planetocentric system with eastward longitudes in the range [0,360[° is expected (practically from 0. to 359.99). By default, the current IAU frame is assumed, in particular for the definition of the prime meridian.

IAU 2009 planetocentric convention [RD12] applies, in particular eastward longitudes and a north pole located on the north side of the invariant plane of the Solar System for planets and satellites; small bodies are always considered prograde and their north pole is defined accordingly (see [RD12] and Annex A for details).
The above definition of C3 (altitude above reference surface, typically the reference ellipsoid) allows the user to easily select data in a region of the atmosphere, which is the main point.

Two other parameters are available to provide different vertical scales, and are mandatory for atmosphere-related services if available/relevant: radial_distance (in km from body center) and alti_shape (in km, measured from local surface, i.e. from the DTM or shape model).

- Has this anything to do with USGS Unified Planetary Coordinates ?

- How do we describe planetary interiors (normally using center distance)? Center distance has to be converter to altitude in the view, even at first order - if large, it probably doesn't need to be very accurate. (c3 is expected to only provide an order of magnitude for the c3 range of the granules, not to be a fine search parameter; e.g. granules are usually expected to be atmospheric profiles, not individual values at different altitudes)

- This is implicitly body-fixed - Planetocentric rotating frames (magnetospheric) are defined as spherical (TBC)

cartesian: (x,y,z) as (c1,c2,c3). This includes spatial coordinates given in pixels.
 Unit is context-dependent…

spherical: (r, theta, phi) as (c1,c2,c3). Angles are defined as in usual spherical systems (E longitude, zenith angle/colatitude), in degrees. If the coordinates are related to the sky, "celestial" coordinates with RA/Dec must be used instead. 


cylindrical: (r, theta, z) as (c1,c2,c3); angles are defined in degrees, radius in km.

spatial_origin used to indicate center of frame in these last 3 cases?

This parameter, although related to the specific coordinate system in use, is mostly intended to identify the nature of the coordinates handled by the service (e. g., angles versus distances).
 This parameter is provided as a column of the epn_core view, to ensure it can be queried through the basic TAP mechanism. Although it will in general remain constant along the table for simple services, this parameter can vary from granule to granule and a value must therefore be provided in any query that includes spatial coordinates. Whenever additional coordinates are provided, they must be stored in extra columns of the table. If several different frames are mixed to provide the main coordinates, the use of different granule_gid may help clarify the situation. At any rate, easy access to the data must drive the design of the service.

Optional parameters:

target_distance

The target_distance parameter introduces the distance of the observer to the observed area, not to be confused with a vertical dimension provided by c3. For ground-based observations this is the geocentric distance of the target. For space borne data, this is the spacecraft-target distance.

Celestial coordinates (ra, dec)

If sky coordinates of the target are provided in the view in addition to standard coordinates, they must be stored in parameters named ra and dec (equatorial). This may document the location of a planet in a celestial image, while the main coordinates c1/c2 are used to describe the observed area as longitude and latitude. RA/Dec parameters are interpreted correctly by most VO tools.

Description of coordinate frame

Spatial_coordinate_description
Spatial_origin

These two parameters provide description of the spatial frame(s) associated to the data, which may differ from the standard (c1,c2,C3) convention as introduced by the spatial_frame_type parameter. Possible values are detailed in [RD17], which is partly adapted from STC [RD13].

(initially we wanted to allow different conventions in the epn-core view but this is extremely unpractical and would preclude uniform queries. In v2, these 2 parameters only describe the coordinates provided with the data.) The spatial_coordinate_description and spatial_origin attributes allow the data provider to indicate different conventions, e. g., to indicate a planetographic frame with westward longitudes, or to use body center distance as the third coordinate.

Spatial_origin may be used to distinguish between altitude and distance from center when body coordinates are in use - TBC.
Examples (TBC)
BODY, Mars_IAU2000, ICRS
 Geocenter 

Ranges and specific definitions vary with the actual frame in use, and are discussed in Appendix A.  

Not allowed in the view (does it make sense for the data?):

healpix: TBC (Nside and pixel#? should also specify pixel ordering: nested/ring?)

Spatial_coordinate_description must indicate the properties of the coordinate frame in use, in particular for body-fixed:

- Type
- Body of interest
- Prime meridian definition
- Origin + altitude vs center distance
- planetographic / centric
- Right/left-handed (can be either if planetographic)
- Control point network?
- Rotational parameters (rate / poles)?
- IAU frame expected for body fixed, but this should specify version or date

Reference frames defined through spice kernels (including 3D shape models) can be referred to using the frame name included in the kernel. For VIRTIS/Rosetta, we use
- a coordinate system name (provided in frame kernels (*.tf) for small bodies, or in generic Spice kernels)
- a DTM provided by an older experiment, or a Spice dsk kernel (*.bds) defining the 3D shape of the body
- a rotation kernel (*.tpc) completed by precession/variation of rotation rate (CATT*.* spice files)

— Is that all?