issue_comments

@TomNicholas I've landed on this discussion looking for a solution for what I consider the exact same problem. Indeed the overlapping is something that all the users of Sentinel 2 Level 1c will figure out. All the observations are deployed to users through a series of tiles following the MGRS grid system. Each tile has an overlapping area with the bordered once and is varying according to the position of the tile in relation to the reference system. Indeed the approach you are describing can solve the problem but would require the analysis of the bounding box and a consequential selection through the .sel(). In Rasterio this can be easily obtained through the .merge module. To have a quick example of how ti is used have a look here

You are right in pointing that there are multiple ways to treat the overlapping values but I would stick with the most common one that is as well reported in the link you mentioned. In other words (min, max, average, first, last) would be already a huge plus.

About dask, indeed is helping a lot to create a delayed object of the tiles (consider that at least for S2 data are in jp2 and we are forced to use open_rasterio instead of open_mfdataset) so the solution should be compatible with this kind of approach. If you need further explanation or I wasn't too clear please let me know.

About Pangeo, indeed a topic should be opened on it and eventually we can move there the discussion but, at least in my opinion, for the moment the right place to discuss is within xarray.

Seems that Sinergise for the AWS service has used the average algorithm to solve the same issue. Seems that all the users that will use the AWS S2 Products will not need to care about the overlap issue.

Edit: update on AWS service

Thanks. The problem is I don't really know where the common coordinates are. However, since I know the extent of each tile, with some preprocessing I should be able to find/trim them.

On the side note. It would be great if mosaicing dataset with common coordinate was added to the xarray (like mosacing rasters). What really happened was I had a large area, then I used xarray to clip it into smaller tiles to make calculations more feasible. After I did the calculations on tiles and decided to stitch them together this problem raised. Your approach would solve this issue, but having it as part of xarray definitely helps many geospatial applications where, for many reasons, we deal with tiles of data with common coordinates. Thanks again.

Thanks @TomNicholas for a thorough explanation. Now it makes sense. I thought this is a process like mosaicing rasters using rasterio.merge. Yes, it would be great if you can add an example on how to find and trim overlapping coordinates. I don't really know how to find common coordinates in spatial datasets using isel.

Thanks