"Correct" ordering of wrf latitude
bnb32 opened this issue · 6 comments
Why this feature is necessary:
Wrf data uses an increasing ordering of latitude, while wtk data uses a decreasing latitude. The makes (0, 0) the index of the lower left corner for wrf data while (-1, 0) is the lower left corner for wtk data. It might not be necessary but it would be nice to have wrf data arranged with the same ordering.
A possible solution is:
We could setup DataHandlerNC.extract_feature to return data after doing data = data[::-1]. This would need to be accounted for when calculating the raster though, and would make direct extraction from xarray.open_dataset disagree with extraction from DataHandlerNC.
Urgency / Timeframe
Definitely not urgent, and might not even be necessary. We can always just do [::-1] after extraction.
This is a good point and might be immediately important for some of the continental scale downscaling, e.g. its probably important to have the N/S oscillation in the correct direction when doing daily->hourly temperature over all of conus
I think it's mostly an aesthetics issue though. As long as the axes are consistent it wouldn't affect the downscaling either way, I don't think. I wouldn't expect the mapping the gan learns to be dependent on orientation. It would still be nice not to have to worry about flipping when plotting.
The GAN kernels could be orientation specific though, couldn't they? I mean just thinking about a conv layer, there's certainly a "right-side up" in the 3x3 kernel. I suspect it might turn out okay but it may also get confused if a cold wave is coming from the south.
Yeah the more I think about it the less sure I am that it wouldn't matter. Worth implementing I suppose.
I think it's worth implementing and it sounds reasonably easy to check the lat ordering and make sure it's right-side-up
Yeah agreed