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 latticeWORLD_SIGHT_VECTOR— the ECEF look direction at each lattice pointLATTICE_POINT— the (sample, line) pixel grid those vectors attach to, in row-major orderIMAGE_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_gdfis indexed by lattice line number rather than time, andatt_dfis None — ASTER reports no attitude at all (see theasp_plot.sensorspackage docstring for that contract).dateis recovered from a neighbouringAST_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#
Metadata reader for ASP |
Module Contents#
- class asp_plot.sensors.aster.AsterMetadata(directory=None, image_list=None)#
Bases:
asp_plot.sensors.base.SensorMetadataMetadata reader for ASP
gen_asterASTER 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_dfis 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.
- 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#