DOI-USGS / lake-temperature-model-prep

Pipeline #1
Other
6 stars 13 forks source link

NDGF lakes: investigate why some aren't passing monotonicity test #126

Open lindsayplatt opened 4 years ago

lindsayplatt commented 4 years ago

The ones listed in "not_working" still have something preventing them from passing monotonicity test. There are 13.

Below is a section of code that I started to test these in munge_ndgf_bathy.

# These don't pass monotonicity but not due to zero area
# Still trying to discover why they don't pass.

# saveRDS(ndgf_bathy, "before_collapse_bathy.rds")
ndgf_bathy <- readRDS("before_collapse_bathy.rds")

# For some, even though the shapes visually pass monotonicity,
# the calculated areas do not. Could have to do with unresolved
# internal boundaries?
# For others, there are a few depths that cause an issue
test_lake_monotonicity <- function(ndgf_bathy, lake_id) {
  ndgf_bathy_test <- ndgf_bathy %>%
    filter(other_ID == sprintf("ndgf_%s", lake_id)) %>%
    select(other_ID, depths, areas) %>%
    arrange(other_ID, depths)
  d <- unique(ndgf_bathy_test$depths)

  sf_shallow <- ndgf_bathy_test %>% filter(depths == d[2])
  sf_deep <- ndgf_bathy_test %>% filter(depths == tail(d, 1))

  # deeper depth shape fits inside shape at shallow depth
  # BUT somehow the area is larger at the deeper
  #   depth when it should be smaller
  area_shallow <- round(st_area(st_polygonize(sf_shallow)), digits=2)
  area_deep <- round(st_area(st_polygonize(sf_deep)), digits=2)

  plot(st_geometry(sf_shallow), main = sprintf("Lake %s", lake_id),
       sub = sprintf("Area shallow: %s || Area deep: %s", area_shallow, area_deep))
  plot(st_geometry(sf_deep), add=T, col = "red")

  return(area_shallow > area_deep)
}

monotonicity_extremes <- c()
for(i in fail_test) {
  test_i <- test_lake_monotonicity(ndgf_bathy, i)
  monotonicity_extremes <- c(monotonicity_extremes, test_i)
}

# See which don't pass the monotonicity test vs which do at the extremes
# The ones that do at the extremes probably have some weirdness with a few
# depths and we can remove those. The ones that don't pass at the extremes
# may be some other issue (especially if they pass the visual test)
pass_test <- not_working[monotonicity_extremes]
fail_test <- not_working[!monotonicity_extremes]

# Pass test lakes
# Lake 285: depths 6 through 18 seem out of place - they don't decrease
# Lake 046: depths 6 through 21 & 27 aren't smaller than depth 3
# Lake 020: decreasing steadily except depth 5 feels out of place.
# Lake 077: depth 3 and depth 12 don't seem right

# Fail test lakes
# Lake 646: passes visual test, fails numeric
# Lake 305: passes visual test, fails numeric
# Lake 085: passes visual test, fails numeric
# Lake 551: incomplete shapes
# Lake 001: incomplete shapes
# Lake 750: passes visual test, fails numeric
# Lake 753: passes visual test, fails numeric
# Lake 751: passes visual test, fails numeric
# Lake 752: passes visual test, fails numeric

# Lake 516 has different issues:  has both positive (not just 0) and negative depths
jordansread commented 4 years ago

I think the "donut" bathymetry contour is the reason for this, right?

lindsayplatt commented 4 years ago

I haven't confirmed that it is the only reason, but I think it may be part of the reason. Although, the issue with those types of scenarios is that they are not being removed in the final area calc right now BUT that would be happening at all depths. So even though the area calc is wrong, they should still pass this test for monotonicity. So I'm not sure if it is the root cause ...

To elaborate on that so it is more obvious when we return to this after the TOHA push: the st_union function is removing the internal boundaries before the area calc. This means that lakes with little islands or sand bars (the "donuts" mentioned above) are getting removed. See image below.

20200302_091113