Some SEAK Communities have no precip or temp

[MikeDelue]

Samples: Hoonah and Klawock

STR: go to tool, use dropdown to select Hoonah
Expected results: Page displays all results including Temp and Precip charts and graphs
Observed results: No information on temp or precip are returned

These are two sample communities where this happens which have been observed by Allison Bidlack. There may be more communities like this. Maybe it's a masking issue?

[MikeDelue]

This issue may be resolved in some cases by ua-snap/geospatial-vector-veracity#96 but we need to vet SEAK communities separately after that PR goes through.

[brucecrevensten]

I guess I don't exactly know the fix here. There's not good data for this place. What are we trying to accomplish, given the varying footprints of datasets? @charparr can you contemplate plz

[MikeDelue]

The problem here is the relative size of these communities and the fact that this seems prevalent in the archipelagic areas. Is there a way to detect and nudge results for named point locations? IE: user asks for https://northernclimatereports.org/report/community/AK153#results but actually gets https://northernclimatereports.org/report/58.11/-135.42#results

[charparr]

Well there are a few different paths here that I can see

• Hack the data look-up as Mike suggested - return the nearest neighbor grid cell that has data. I think we've implemented this strategy somewhere once before. @cstephen does this ring any bells?
• Hack the data look-up by mapping to a HUC-12 summary instead
• Don't crop our data coverages in preprocessing, or massively reduce the crop extent, when we use them for WCS requests. In the case of WRF derived outputs, there are data everywhere (ocean, land etc.). If we don't crop these data, then Hoonah and Klawock and the like will have data. However, the WMS requests to that same coverage might not look as pretty (you wouldn't see the coastline, for example). However, that could probably be worked around if needed.
• Some datasets just won't have data for these coastal locations. In those instances you'd need to pad the arrays.

The easiest thing to do here is probably just to change the lat-lons that represent these communities in the GVV repo! As long as the change isn't drastic, like greater than the hypotenuse of a 20 km X 20 km grid cell, I think it is defensible.

But moving forward with new datasets we need to be careful to retain the broadest extent of data possible.

[cstephen]

Regarding hacking the data look-up to return the nearest neighbor grid cell, yep, we have implemented this once already for the Community Charts data extraction script:

https://github.com/ua-snap/cc-data-extraction/blob/main/extract.py#L244

This code starts out at the community's lat/lon point and then spirals out until it finds something. But it also allows us to specify a hard limit for how far away it can look to find valid data. I'm sure we could add similar code to the data-api to do the same thing if we decide to go that route, with a few days of work and testing.

For the Community Charts tool, we were able to find data by looking just 1 grid cell away, but this might not be the case for the latest set of locations in geospatial-vector-veracity.

[charparr]

Thanks Craig - that is exactly what I was thinking of!

We'd need a sane limit on how far to look, yeah, because for some datasets (like the NCAR VIC Hydrology stuff I'm working on now) there are places where yeah the grid cell is just one away and we can defensibly grab that data I think, and then there are others like Ketchikan where you'd think that would be the case but closest grid cell with data is like hundreds of miles away.