Xarray combine_by_coords return the monotonic global index error
See original GitHub issueI asked this question on Stackoverflow and someone mentioned it might be a bug.
I am trying to combine two spatial xarray datasets using combine_by_coords. These two datasets are two tiles next to each other. So there are overlapping coordinates. In the overlapping regions, the variable values of one of the datasets is nan.
I used the “combine_by_coords” with compat=‘no_conflicts’ option. However, it returns the monotonic global indexes along dimension y error. It looks like it was an issue before but it was fixed (issue 3150). So I don’t really know why I get this error. Here is an example (the netcdf tiles are here):
import xarray as xr
print(xr.__version__)
>>>0.15.1
ds1=xr.open_dataset('Tile1.nc')
ds2=xr.open_dataset('Tile2.nc')
ds = xr.combine_by_coords([ds1,ds2], compat='no_conflicts')
>>>...
ValueError: Resulting object does not have monotonic global indexes along dimension y
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
Xarray combine_by_coords return the monotonic global index ...
I used the "combine_by_coords" with compat='no_conflicts' option. However, it returns the monotonic global indexes along dimension y error.
Read more >xr.combine_by_coords raises ValueError if identical ... - GitHub
Running the example with yCoord = ['a', 'c', 'b'] raises an error: ValueError: Resulting object does not have monotonic global indexes along ...
Read more >pydata/xarray - Gitter
does combine_by_coords do a check for monotonic coordinates when the auto combine did not? ... the dimension does indeed not have monotonic global...
Read more >xarray.combine_by_coords
This function attempts to combine a group of datasets along any number of dimensions into a single entity by inspecting coords and metadata...
Read more >xarray.combine_by_coords — xarray 0.13.0 documentation
Will attempt to order the datasets such that the values in their dimension coordinates are monotonic along all dimensions. If it cannot determine...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @hamiddashti , based on your description then this isn’t a bug, it’s throwing the error it should be throwing given your input. However I can now see how the documentation doesn’t make it very clear as to why this is happening!
combine_by_coords
andcombine_nested
do two things: they concatenate (usingxr.concat
), and they merge (usingxr.merge
). The concatenate step is never supposed to handle partially overlapping coordinates, and thecombine
functions therefore have the same restriction.That error is an explicit rejection of the input you gave it: “you gave me overlapping coordinates, I don’t know how to concatenate those, so I’ll reject them.” Normally this makes sense - when the overlapping coordinates aren’t NaNs then it’s ambiguous as to which values to choose.
In your case then you are asking it to perform a well-defined operation, and the discussion in the docs about merging overlapping coordinates here implies that
compat='no_conflicts'
would handle this situation. Unfortunately that’s only forxr.merge
, notxr.concat
, and so it doesn’t apply forcombine_by_coords
either.merge
deals with variables of the same size,concat
joins variables of different sizes onto the ends of one another. This is definitely confusing.It might be possible to generalise the
combine
functions to handle the scenario you’re describing (where the overlapping parts of the coordinates are specified entirely by the non-NaN values), but I don’t really think it’s a good idea for complexity reasons.(Issue #3150 was about something else, an actual bug in the handling of “coordinate dimensions which do not vary between each dataset”.)
Instead, what you need to do is trim off the overlap first. That shouldn’t be hard - presumably you know (or can determine) how big your overlap is, and all your NaNs are on one dataset. You just need to use the
.isel()
method with a slice. Once you’ve got rid of the overlapping NaNs then you should be able to combine it fine (and you shouldn’t need to specifycompat
either). If you’re usingcombine_by_coords
as part of opening many files withopen_mfdataset
then it might be easier to write a trimming function which you apply first using thepreprocess
argument toopen_mfdataset
.Would it be clearer if I added an example to the documentation where some overlapping data had to be trimmed first?
@pl-marasco I’ve just been pointed to this issue on pangeo-data, which looks like a better place to discuss this.