Skip to content

search_data should warn when spatial parameters are used with a "no-spatial" collection #1314

@danielfromearth

Description

@danielfromearth

Related to #1305 (fix in #1309) and #515.

When the bounding_box parameter (probably for polygon and point parameters too) is passed to search_data() for a collection with no spatial metadata (e.g., TEMPO_IRR_L1, version V04), the search silently returns an empty list. There is no warning or indication that the spatial parameter is the reason for zero results, and the silent [] leads users to believe the data simply don't exist.

This is the inverse of #515, where spatial filters silently match everything for global collections:

Scenario Collection Type Spatial filter effect User experience
#515 Global (every granule covers full Earth) Matches everything "Why didn't my bbox narrow the results?"
This issue No-spatial (no spatial metadata) Matches nothing "Why is there no data?"

Both could benefit from a collection-level check of spatial metadata to inform users when their spatial parameters won't behave as intended.

Reproducing

import earthaccess

# Returns 45 results — no spatial filter
results = earthaccess.search_data(
    short_name="TEMPO_IRR_L1",
    version="V04",
    temporal=("2023-08-01", "2025-09-20"),
)
print(len(results))  # 45

# Returns 0 results — bounding_box silently filters everything out
results = earthaccess.search_data(
    short_name="TEMPO_IRR_L1",
    version="V04",
    temporal=("2023-08-01", "2025-09-20"),
    bounding_box=(-180, -90, 180, 90),
)
print(len(results))  # 0 — no warning

Possible Approach

Before or during granule search, earthaccess could check the parent collection's UMM-C for spatial coverage type. If it indicates no spatial coverage and spatial search parameters are present, earthaccess could emit a warnings.warn(), optionally drop the spatial parameters, or raise an informative error. Perhaps this could also be handled partly in python-cmr. A similar check could potentially address #515 as well.

Context

We encountered this at NASA ASDC with TEMPO irradiance data, a solar measurement with no Earth spatial footprint. The GES DISC team independently hit the same kind of problem with gnssro_cosmic1_jpl_l1b (#1305, though that issue focuses on the __repr__ exception). This likely affects any collection without spatial metadata — solar irradiance, calibration, and other non-Earth-pointing products.

Environment

  • earthaccess: 0.15.1
  • Python: 3.11.13

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions