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
Related to #1305 (fix in #1309) and #515.
When the
bounding_boxparameter (probably forpolygonandpointparameters too) is passed tosearch_data()for a collection with no spatial metadata (e.g.,TEMPO_IRR_L1, versionV04), 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:
Both could benefit from a collection-level check of spatial metadata to inform users when their spatial parameters won't behave as intended.
Reproducing
Possible Approach
Before or during granule search,
earthaccesscould check the parent collection's UMM-C for spatial coverage type. If it indicates no spatial coverage and spatial search parameters are present,earthaccesscould emit awarnings.warn(), optionally drop the spatial parameters, or raise an informative error. Perhaps this could also be handled partly inpython-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