asp_plot.sensors.aster#

Derived stereo geometry for ASTER gen_aster camera XMLs.

Every other reader in this package parses the geometry a vendor wrote down. ASTER has none to parse: ASP’s gen_aster writes an <isd> camera file (ASTER_XML.cc) with no timestamps, no attitude, no view- or sun-angle summary and no footprint corners. What it does carry is the raw material to derive the geometry:

  • SAT_POS — satellite ECEF positions, one per row of the lattice

  • WORLD_SIGHT_VECTOR — the ECEF look direction at each lattice point

  • LATTICE_POINT — the (sample, line) pixel grid those vectors attach to, in row-major order

  • IMAGE_COLS / IMAGE_ROWS — the image extent the lattice spans (the lattice deliberately overshoots it by a few hundred lines)

Intersecting each look ray with the WGS84 ellipsoid turns that into a ground lattice, and everything the stereo-geometry code needs follows from it: the footprint (the image border traced through the ground lattice), the satellite azimuth/elevation at the scene center, the off-nadir/in-track/cross-track view angles at the spacecraft, and the ground sample distance.

Two derivations are worth stating plainly, because they set the accuracy of everything downstream:

  • Rays are intersected with the ellipsoid (h=0), not with terrain. The footprint therefore shifts by h * tan(off-nadir) — under a kilometre for the nadir band and a couple for the backward one over high terrain. View angles are unaffected: moving the ground point along its own ray does not change the ray’s direction, only the (negligible) local vertical.

  • Time is not derivable. There is no timestamp anywhere in the camera file, so eph_gdf is indexed by lattice line number rather than time, and att_df is None — ASTER reports no attitude at all (see the asp_plot.sensors package docstring for that contract). date is recovered from a neighbouring AST_L1A_* granule name when one is present, which means both bands of a pair report the same acquisition time even though the backward look trails the nadir look by roughly a minute.

Unlike the DIMAP-family readers, this one is validated against real data: the committed gen_aster fixtures reproduce ASTER’s published geometry — a 27.6° backward in-track pointing for band 3B, ~15 m GSD, and a footprint matching the camera file’s own RPC bounding box (#175).

Attributes#

Classes#

AsterMetadata

Metadata reader for ASP gen_aster ASTER camera XMLs.

Module Contents#

class asp_plot.sensors.aster.AsterMetadata(directory=None, image_list=None)#

Bases: asp_plot.sensors.base.SensorMetadata

Metadata reader for ASP gen_aster ASTER camera XMLs.

One scene per band file, so a 3N/3B pair goes through the existing N-choose-2 pair machinery with no special-casing: the derived view angles reproduce ASTER’s nadir/backward stereo geometry (~31° convergence at the ground for the nominal 27.6° backward pointing).

See the module docstring for what is derived and what is unavailable. In short: footprint, view angles, GSD and a positions-only trajectory are derived; attitude does not exist (att_df is None), sun angles and cloud cover are absent, and the date comes from a neighbouring L1A granule name if there is one.

get_scene_dict(xml, geteph=True)#

Get a dictionary of metadata for one ASTER band.

Parameters:
  • xml (str) – Path to the gen_aster camera XML.

  • geteph (bool, optional) – Whether to include the trajectory block, default is True.

Returns:

Sensor-agnostic scene dict (see the package docstring).

Return type:

dict

get_scene_dicts()#

Return one sensor-agnostic scene dict per camera XML.

name = 'ASTER'#
asp_plot.sensors.aster.WGS84_A = 6378137.0#
asp_plot.sensors.aster.WGS84_B = 6356752.314245179#
asp_plot.sensors.aster.logger#