Improve handling of bboxes and intervals

[bmcandr]

Related Issue(s):

• SpatialExtent value type checking allows creation of invalid Collections #1267

Description:

• Allow SpatialExtent.bboxes to be a nested list of floats and/or integers to reflect the STAC spec typing of [[number]].
• In SpatialExtent, wrap bboxes in a list if passed as list of floats OR integers.
• In TemporalExtent, wrap intervals in a list if passed as a single interval.

While the linked issue discusses adding more robust validation/coercion of inputs, I opted to start simple because stricter checks on bboxes start to get a little gnarly:

        if all(isinstance(coord, (float, int)) for coord in bboxes):
            self.bboxes = [cast(list[float | int], bboxes)]
        elif all(
            all(
                isinstance(coord, (float, int)) for coord in bbox
            ) for bbox in bboxes
        ):
            self.bboxes = cast(Bboxes, bboxes)
        else:
            raise TypeError(f"unexpected type encountered in bboxes: {bboxes}")

If stricter checks are preferred, I can make that change. I can also add a version of test_spatial_allows_single_bbox to cover single bbox of ints if it's warranted.

PR Checklist:

• pre-commit hooks pass locally
• Tests pass (run scripts/test)
• Documentation has been updated to reflect changes, if applicable
• This PR maintains or improves overall codebase code coverage.
• Changes are added to the CHANGELOG. See the docs for information about adding to the changelog.

[gadomski]

Thanks for the contribution, makes sense to me. Can you add unit tests demonstrating the fix behavior for temporal intervals and expecting the type error for bounding boxes?

[bmcandr]

I added the requested tests.

FWIW, Pylance suggests that the isinstance(bboxes|intervals, list) checks are unnecessary because they should always be lists per the type hints. OTOH explicit is better than implicit. Any preference?

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Files	Coverage Δ
pystac/collection.py	97.00% <100.00%> (+0.82%)	⬆️

📢 Thoughts on this report? Let us know!.