eoio.readers.gistda_theos.layout module

eoio.readers.gistda_theos.layout - helper for GISTDA THEOS file layout parsing.

class eoio.readers.gistda_theos.layout.GISTDATHEOSLayout(product_dir: Path)

Bases: object

Filesystem/layout helper for GISTDA THEOS DIMAP products.

Expects an already-extracted product directory, same as every other get_extension() == "" reader here (e.g. Landsat): a zip/tar archive is extracted upstream by eoio.utils.read_utils.setup_file(), the common entry point every reader is constructed through (eoio.interface.read(), product_options, …), before the reader – and so this layout – ever sees the path. Callers that build a reader directly instead (bypassing that common entry point) are responsible for extracting first.

product_dir may or may not directly hold METADATA.DIM/IMAGERY.TIF – see dimap_dir.

aux_data_dir(aux_name: str | None = None) → Path | None

aux_dir() → Path

aux_path(aux_name: str) → Path | None

property dimap_dir: Path

The directory directly holding METADATA.DIM/IMAGERY.TIF.

A THEOS delivery zip’s top level holds loose wrapper files (README/PDF/ LOGO) alongside one folder actually named for the product id – extracting such a zip (see eoio.utils.read_utils.extract_zipped_file()) wraps all of that, DIMAP folder included, in one container directory named for the outer (order-derived) zip filename. So product_dir (that container) does not directly hold METADATA.DIM/IMAGERY.TIF – its one subdirectory that does, does.

Also accepts product_dir already being that DIMAP folder directly (METADATA.DIM present at its own top level) – e.g. an archive laid out by hand with the wrapper files discarded, not derived from extracting a real delivery zip.

Raises:

GISTDATHEOSLayoutError – neither product_dir itself nor exactly one of its immediate subdirectories holds a METADATA.DIM.

image_file() → str

metadata_file() → Path | None

product_dir: Path

property tif_img_pardir_path: Path

exception eoio.readers.gistda_theos.layout.GISTDATHEOSLayoutError

Bases: ValueError