Skip to content

Conversation

@adamkemberling
Copy link
Collaborator

I think the language could be cleaner, but this is how I have been processing zonal summaries. There are a couple steps to follow:

  1. Open an FVCOM .nc file that has Lon/lat values to create a mesh. (this only needs to be done once, and will be buggy if its done each time since lat/lon sometimes are zeros on the THREDDS links)
  2. Get geometric intersection of polygon and the mesh: get_poly_mesh_intersection()
  3. Process the zonal average for all polygons in the intersection, this takes average of the three nodes: get_mesh_element_timeseries(), using get_average_from_nodes() on each element.
  4. Get the zonal average by weighting each element-wise time series by its area (after intersection, so accounting for partial areas): get_area_weighted_zonal_average()

The function get_timeseries_for_poly() is a wrapper around doing steps 2-4.

Each of these need namespace bindings to be added, but I wanted to just contribute something to feel like I've done something.

@adamkemberling adamkemberling added the enhancement New feature or request label Aug 20, 2024
@btupper
Copy link
Member

btupper commented Sep 17, 2024

@adamkemberling I have let this slipped - sorry! How about changing the "zonal" language to "roi" for region of interest?

@adamkemberling
Copy link
Collaborator Author

I like the roi language much more than the zonal, I can tweak that and then tidy it up for a merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants