Add tests for computation.py pure-logic functions - #95
Conversation
Tests for contiguous_regions (8 cases covering single/multiple blocks, all-true/all-false, alternating, numeric conditions), coords_to_utm (5 cases including Alaska, NYC, southern hemisphere, zone boundaries), and barometric_pressure (3 cases against known physical values). These are the highest-ROI test targets: pure numpy/math with no external dependencies, used throughout the pipeline. Signed-off-by: arpitjain099 <arpitjain099@gmail.com>
| result = coords_to_utm(-33.87, 151.21) | ||
| assert result == "epsg:32756" | ||
|
|
||
| def test_prime_meridian(self): |
There was a problem hiding this comment.
@dbetchkal - curious for your input on an issue this test prompted me to look into.
These tests are indeed verifying that coords_to_utm does what it's written to do, but coords_to_utm itself does not seem set up to handle coordinates outside of the NAD83 zone in the Northern Hemisphere.
It's hardcoded to return EPSG:269 as the prefix in the northern hemisphere, but that's only applicable for NAD83.
We use EPSG:327 as the prefix in the southern hemisphere (which is the WGS 84 prefix). The equivalent EPSG prefix for northern hemisphere under the WGS 84 datum would be EPSG:326.
I suppose since we're the US NPS, we've historically been more focused on sites that fall on the North American continent, but it does raise the question of if we want the coords_to_utm function to be more general.
It seems the simplest way to fix the function would be to use WGS84 consistently for all cases. However, that adds the complexity of deciding when to convert back to NAD83 if applicable for NMSIM. There's also the question of what datum input coordinates are in.
We could also consider something like the pyproj query_utm_crs_info function which would likely be a bit more robust as it queries a local copy of the EPSG database. However, the question about when to return EPSG:269 (NAD83) vs EPSG:326 (WGS84) arises.
Secondary question - do we care about the inconsistency in the current coords_to_utm implementation of returning NAD83 for northern hemisphere vs WGS84 for southern hemisphere
(Final point - how much does NAD83 vs WGS84 matter for our case since the offset is only a few meters? Regardless, I think it's good to document/make a clear decision on the datum we're using)
| npt.assert_array_equal(result, [[1, 3], [5, 6]]) | ||
|
|
||
|
|
||
| class TestCoordsToUtm: |
There was a problem hiding this comment.
#75 changed the return signature for coords_to_utm to return a tuple, so we would want to rebase and update this PR to reflect/test the new signature
2 participants
Adds test coverage for three functions in computation.py that had zero tests and no external dependencies (pure numpy/math).
contiguous_regions (8 test cases) - finds contiguous True regions in a boolean array. Tested with single block, multiple blocks, all true, all false, single element, alternating pattern, and numeric condition input.
coords_to_utm (5 test cases) - converts lat/lon to UTM EPSG codes. Tested with Denali Alaska (zone 5), New York (zone 18), southern hemisphere Sydney (zone 56), near the prime meridian, and a zone boundary.
barometric_pressure (3 test cases) - implements the barometric formula for atmospheric pressure at altitude. Verified sea level returns 101.325 kPa, pressure decreases monotonically with altitude, and 1500m falls in the expected 80-90 kPa range.
These are high-ROI test targets since contiguous_regions is imported by both metrics.py and models.py, and coords_to_utm is used throughout the pipeline for CRS handling.