You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Performance of extract_points vs rasterio sample #81
Under the hood, extract_points is simply passing the coordinates to .sel with method='nearest', which should be doing exactly the same as rasterio's sample.
We could possibly use sample via rioxarray if the raster is loaded via xarray as it is available through dtm_da.rio._manager.acquire().sample(list(zip(x, y))) but that is relying on a private API of rasterio. I'll open an issue there if there's an appetite to expose sample on the rio accessor.
Outside of relying on rasterio, is there a way of speeding it up using some xarray magic?
This massive difference happens only when we need to load practically whole raster into memory, as is the case in the notebook sampling points across the whole extent. If I sample points only from a small spatial subset (a 2x2km square in the corner), xvec is actually faster than rasterio, which does not seem to care about the spatial distribution of points.
Also, if the whole array is loaded in memory, we are faster.
It seems that no matter what, rasterio is able to load only the pixels needed.
We should at least document this behaviour and point to sample if the use case requires heavy sampling over the whole area.
Outside of relying on rasterio, is there a way of speeding it up using some xarray magic?
I made some comments over in the rioxarray issue explaining where the slowness is coming from, but currently it's at least the same order of magnitude to simply loop over the points :) I could create a pull request to modify extract_points if it seems like a good idea:
# Wall time: 399 ms compared to 6s for me running the example notebook abovepts_da=np.zeros_like(x)
fori,pinenumerate(points):
pts_da[i] =dtm_da.sel(x=p.x, y=p.y, method="nearest").squeeze().to_numpy()
I could create a pull request to modify extract_points if it seems like a good idea
This helps only when the raster is lazily loaded, right? If it is all in memory, then the current solution is going to be faster I suppose.
I assume that people will mostly care about the performance of the lazy mode so I'd be keen on looping here as you suggest until the discussion in rioxarray will move further.
Activity
martinfleis commentedon Aug 29, 2024
Further observations:
This massive difference happens only when we need to load practically whole raster into memory, as is the case in the notebook sampling points across the whole extent. If I sample points only from a small spatial subset (a 2x2km square in the corner), xvec is actually faster than rasterio, which does not seem to care about the spatial distribution of points.
Also, if the whole array is loaded in memory, we are faster.
It seems that no matter what, rasterio is able to load only the pixels needed.
We should at least document this behaviour and point to
sampleif the use case requires heavy sampling over the whole area.scottyhq commentedon Jan 6, 2025
I made some comments over in the rioxarray issue explaining where the slowness is coming from, but currently it's at least the same order of magnitude to simply loop over the points :) I could create a pull request to modify extract_points if it seems like a good idea:
martinfleis commentedon Jan 18, 2025
This helps only when the raster is lazily loaded, right? If it is all in memory, then the current solution is going to be faster I suppose.
I assume that people will mostly care about the performance of the lazy mode so I'd be keen on looping here as you suggest until the discussion in
rioxarraywill move further.