Typecheck spatial module

[mfisher87]

No description provided.

[github-actions]

👈 Launch a binder notebook on this branch for commit e314990

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit 7b563b1

👈 Launch a binder notebook on this branch for commit 1f1cfe5

👈 Launch a binder notebook on this branch for commit 749fc03

👈 Launch a binder notebook on this branch for commit a63ae13

👈 Launch a binder notebook on this branch for commit bfa9562

👈 Launch a binder notebook on this branch for commit 153c307

👈 Launch a binder notebook on this branch for commit e0ef967

👈 Launch a binder notebook on this branch for commit 130160b

👈 Launch a binder notebook on this branch for commit 830f471

👈 Launch a binder notebook on this branch for commit 0ca4485

👈 Launch a binder notebook on this branch for commit b035695

👈 Launch a binder notebook on this branch for commit cbc761c

👈 Launch a binder notebook on this branch for commit 52037e9

👈 Launch a binder notebook on this branch for commit 7c64991

👈 Launch a binder notebook on this branch for commit 2adc38d

👈 Launch a binder notebook on this branch for commit 9df3ec7

👈 Launch a binder notebook on this branch for commit 6f771d8

👈 Launch a binder notebook on this branch for commit 3f923a6

👈 Launch a binder notebook on this branch for commit 27de548

👈 Launch a binder notebook on this branch for commit 191181e

👈 Launch a binder notebook on this branch for commit 9aa54dc

👈 Launch a binder notebook on this branch for commit 207be53

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.62%. Comparing base (c454aab) to head (207be53).

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #605      +/-   ##
===============================================
- Coverage        71.81%   67.62%   -4.19%     
===============================================
  Files               38       36       -2     
  Lines             3136     3138       +2     
  Branches           426      429       +3     
===============================================
- Hits              2252     2122     -130     
- Misses             774      932     +158     
+ Partials           110       84      -26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JessicaS11]

@mfisher87 Any idea if this was rebased after merging #604? Trying to determine where to start for fixing merge conflicts and moving this forward.

[mfisher87]

Rebased this PR (and #612 and #613) and fixed merge conflicts!

[JessicaS11]

Suggested change

	spatial_extent: Union[str, list[float]],
	spatial_extent: Union[str, list[float, tuple[float]], Polygon],

Is this the proper way to do this? The list can be a list of floats or a list of tuples (which contain floats)?

[trey-stafford]

Just to confirm, should this also accept a Polygon?

Assuming that's the case, I think this is what we would want:

Suggested change

	spatial_extent: Union[str, list[float]],
	spatial_extent: Union[str, list[float], list[tuple[float, ...]], Polygon],

This accepts either a string, a list of floats, a list of tuples containing floats, or a Polygon.

Edit: I tried adding this annotation to the code and ran pyright. This change resulted in 23 errors that will need to be resolved.

[trey-stafford]

I'm tackling this incrementally. Added support for Polygon input with: 1c1c490

[trey-stafford]

And this adds support for the list[tuple[float, float]] case: 52037e9. I also add unit tests for each of these new cases.

[JessicaS11]

Hmmm... I'm surprised this resulted in so many errors (I haven't gotten fully up to speed on pyright, so I was just trying to make the typing match what the code already did). It should have already been handling Polygons (now circa line 137) and lists (of either floats or tuples, now circa line 140). I wonder if pyright is choking on the fact that which types are valid for spatial_extent depends on the input for extent_type?

Thanks for adding those tests!

[trey-stafford]

Part of the reason was subsequent function calls also being typed without support for Polygons and lists of tuples w/ floats. Not as difficult to resolve as I initially feared when making the change!

Happy to add the tests - I'll try to add more where I can as I'm working through this harmony transition work!

[JessicaS11]

Part of the reason was subsequent function calls also being typed without support for Polygons and lists of tuples w/ floats. Not as difficult to resolve as I initially feared when making the change!

Ah - that makes sense (and is certainly far less challenging to deal with). Thanks for doing so!

Happy to add the tests - I'll try to add more where I can as I'm working through this harmony transition work!

You would be my hero!

I think the only thing still outstanding for this PR is we still need to resolve the duplicate functionality for handling Polygons (lines 85 + 135) and lists (92+140) that was added in your above linked commits. I think the original ordering got confusing when @mfisher87 moved the if file is True bit to the top, so it transitioned from handling all extent_type==bounding_box and then all extent_type==polygon cases to handling extent_type==polygon if it's from a file, extent_type==bounding_box, and then the rest of the extent_type==polygon cases. I don't think it particularly matters what order we do things in, so perhaps moving the rest of the polygon handling above the bounding_box handling is the clearest thing to do?

[JessicaS11]

Rebased this PR (and #612 and #613) and fixed merge conflicts!

Thanks, @mfisher87! This PR is pretty close - a few suggestions where we may need to make type adjustments (would love a second set of eyes on these) EDIT: DONE and some notes for some docstring and error message edits.

[trey-stafford]

@JessicaS11 just a heads-up that I am beginning to review and work on the Harmony integration tasks that @mfisher87 started, beginning with this PR. I'll be looking over things here and will try to respond to your comments this afternoon!

[trey-stafford]

Not sure about the failing codecov/project check but I have added some additional unit tests to cover branches identified by codecov as not being covered by this PR.

Aside from that issue, this should be ready for re-review!