Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

staticmaps.nc to gtiff and back #37

Closed
jurianbeunk opened this issue Jun 22, 2021 · 5 comments
Closed

staticmaps.nc to gtiff and back #37

jurianbeunk opened this issue Jun 22, 2021 · 5 comments
Labels
bug Something isn't working

Comments

@jurianbeunk
Copy link
Collaborator

Converting staticmaps.nc to gtiff and back to staticmaps.nc as described here:
https://deltares.github.io/hydromt_wflow/latest/examples/examples/convert_staticmaps_to_gtiff.html

Results in bad maps (striped patterns in the maps) even without editing any of the gtiff rasters.

ds_updated = hydromt.open_mfraster(join(root, 'staticmaps', '*.tif')) does create good maps (when exporting ds_updated to .nc file), but writing it back to a model (i.e. mod.set_staticmaps(ds_updated) & mod.write() seems to create the issue somehow.

@jurianbeunk
Copy link
Collaborator Author

jurianbeunk commented Jun 23, 2021

Other, but potentially related issue:

Running hydromt update to setup_gauges, based on a .gpkg file providing the gauge locations, results in a staticmap (i.e. wflow_gauges) with missing gauges, even though hydromt finds all gauge locations in domain.

@hboisgon
Copy link
Contributor

From Huite:
I notice that that the values are located in the right place; all the spatial patterns appear to be the same. So I'm quite confident that you're running into one of my least favorite features of xarray: the automatic alignment. Somewhere in the workflow, two different datasets are being combined (e.g. via some arithmetic operation). Xarray will look for the intersection of the coordinates here (i.e. the coordinates that are available in both datasets).

The problem here is being caused by having a dataset with e.g. 500 m resolution versus one with 100 m resolution. In this case, xarray will select the coordinates that are available in both and compute a result with just that.

So my guess is, if you know which dataset has a different cellsize and is being used in this workflow, you can fix the issue by changing that dataset to the appropriate cellsize (at the start)

@hboisgon
Copy link
Contributor

The problem indeed comes from calling the set_staticmaps line 'too soon' (without any further processing of the mapstack).
Additionally Wflow staticmaps has two parameters with a third dimension (layer for c and time for LAI) so anyway more processing is needed than just read and write.

In #42 I renamed the notebook to convert_staticmaps_to_mapstack and recommend to use the built-in read_staticmaps_pcr and write_staticmaps_pcr in order to be able to use hydromt to manually update wflow staticmaps.

@DirkEilander : shall we add some extra lines in set_staticmaps in order to check that the new data has the same grid/dimensions and if not throw an error?

@DirkEilander
Copy link
Contributor

@hboisgon good suggestion! I think we can simply added join='exact' to the xarray.merge method. see https://xarray.pydata.org/en/stable/generated/xarray.merge.html

@DirkEilander DirkEilander added the bug Something isn't working label Dec 3, 2021
@hboisgon
Copy link
Contributor

Closed as fixed in setup_grid in hydromt core

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants