Skip to content

6296: pick the first usable Location in a spatial array, not first truthy - #925

Merged
cody-seibert-gsa merged 9 commits into
mainfrom
fix-spatial-array-first-usable
Sep 10, 2026
Merged

6296: pick the first usable Location in a spatial array, not first truthy#925
cody-seibert-gsa merged 9 commits into
mainfrom
fix-spatial-array-first-usable

Conversation

@cody-seibert-gsa

Copy link
Copy Markdown
Contributor

Summary

_unwrap_location() selected the first truthy element of a spatial Location array, not the first usable one. A non-empty dict with no geometry (e.g. a prefLabel-only Location) is just as truthy as one with a bbox, so [{prefLabel-only}, {bbox-bearing}] resolved to NULL while the reverse order worked fine - whether the record kept its geometry depended on element order in the source feed, not on which element actually had any.

What changed

  • Split _unwrap_location into _unwrap_single_location (the existing single-Location logic, unchanged) plus a list loop that returns the first element _unwrap_single_location resolves to something truthy, instead of picking the first truthy raw element up front.
  • Added unit tests for the previously-broken reversed order, and for an array where nothing is usable.

Closes GSA/data.gov#6296

…uthy

_unwrap_location() picked the first truthy element of a spatial Location
array, which is wrong when that element is a Location with no usable
geometry (e.g. prefLabel-only). A later element with a real bbox/geometry/
centroid was silently dropped, so translated_spatial depended on element
order in the source feed rather than which element actually had geometry.

Closes GSA/data.gov#6296
Comment thread tests/unit/test_utils.py
_unwrap_location discarded a Location's prefLabel outright when no
geometry/bbox/centroid was present, so a named place like "Nebraska"
never reached the existing get_geo_from_string locations-table lookup
in translate_spatial and always resolved to "". Real geometry anywhere
in the input still wins; the prefLabel is only used as a fallback when
nothing in the whole input has usable geometry.
Comment thread tests/unit/test_utils.py Outdated
test_translate_spatial_location_array_skips_unusable_leading_element used
the same input and primary assertion as
test_translate_spatial_location_array_geometry_after_pref_label_skips_lookup,
which also asserts the locations-table lookup is never attempted -
strictly more coverage of the same case. Per rshewitt's review comment.
…ov-harvester into fix-spatial-array-first-usable

@rshewitt rshewitt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good!

@cody-seibert-gsa
cody-seibert-gsa merged commit 5560308 into main Sep 10, 2026
8 checks passed
@cody-seibert-gsa
cody-seibert-gsa deleted the fix-spatial-array-first-usable branch September 10, 2026 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

spatial arrays pick the first *truthy* Location, not the first *usable* one

2 participants