[Bug]: Project Raster (#953) bilinear differs from gdalwarp when downsampling and next to no-data
Maintainers usually reply within 1 day
@GISspecialistAlejandraDuque is already working on this.
Since Oct 27, 2026.
- #1039 by @GISspecialistAlejandraDuque — open
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by reading issue #953 and the raster.project resampling implementation, then compare its bilinear behavior with the supplied gdalwarp commands on both downsampling and no-data cases. The issue leaves open whether downsampling should widen the kernel or be documented as point-wise, and whether centre-on-no-data cells should remain no-data; done means those behavior choices are resolved and the corresponding results are documented or match the agreed expectation.
Written by the indexing model from the issue text.
Description
What happened?
I compared raster.project with gdalwarp (GDAL 3.13.1) on the same output grid. For each case, gdalwarp got the exact CRS, bounds and size of RustGIS's output. The input is a 25 m DEM of Val Venosta (EPSG:25832, Float32, 1865 × 1373, no-data 0 on 107,345 cells) and its slope classes (Byte, 7 classes and a colour table).
These agree with GDAL:
| Case | Result |
|---|---|
average, 100 m, same CRS (4 × 4 pixels per cell) |
all 153,925 cells within 0.0002 |
nearest, 25 m, to EPSG:3003 (Monte Mario / Italy zone 1, with the datum shift) |
all 2,453,300 cells identical |
nearest, 100 m, to EPSG:3035 |
153,386 of 153,392 cells identical |
mode differed in its ties; PR #972 makes it follow GDAL, and it then matches in all 153,537 cells. Two differences remain, both in bilinear, and both look like choices for you to make, so I didn't change them:
1. bilinear doesn't widen the kernel when downsampling. DEM at 100 m to EPSG:3035 (4× coarser): only 0.2 % of cells are equal; the mean difference is 3.24 m and the largest 40.0 m. gdalwarp scales the bilinear kernel to the output cell when the output is coarser. Disabling that (-wo XSCALE=1 -wo YSCALE=1) makes GDAL agree with RustGIS: largest difference 0.0037 m. #953 says bilinear and cubic sample at the cell centre, so this may be intended; then a sentence in the docs would help, since the result aliases where gdalwarp smooths. I didn't test cubic.
2. bilinear gives a value to cells whose centre falls on a no-data pixel. RustGIS fills 3,205 cells that gdalwarp leaves as no-data (DEM at 25 m to EPSG:3003), and 201 at 100 m to EPSG:3035. For all of them, the source pixel under the cell's centre is no-data. GDAL then writes no-data, and otherwise renormalises over the valid neighbours. In the EPSG:3003 case, the cells valid in both agree within 0.0005 m. The same difference was reported for terrio's warp in opengeos/terrio#307.
Steps to reproduce
rustgis-cli run --data dem.tif --cmd 'raster.project={"layer":"dem","crs":3035,"cellSize":100,"resampling":"bilinear","path":"rg.tif"}'
# gdalwarp on the same grid: CRS, -te and -ts read from rg.tif
gdalwarp -t_srs EPSG:3035 -te <xmin ymin xmax ymax of rg.tif> -ts <width height of rg.tif> -r bilinear -srcnodata 0 -dstnodata 0 -et 0 dem.tif gdal.tif
The same with "crs":3003,"cellSize":25 for the cells next to no-data.
Expected behavior
The same values as gdalwarp: (1) a kernel scaled to the output cell for bilinear and cubic when downsampling, or a note in the docs that they sample point-wise; (2) no-data where the pixel under the cell's centre is no-data. If you'd like either, I can open a pull request.
How are you running RustGIS?
rustgis-cli from a Windows build made by the Release workflow on my fork: main at 9285e05 plus an unrelated legend change (#889).
Version
main 9285e05 (after v0.4.0)
Operating system, browser and graphics
Windows 11
Sample data
Copernicus DEM GLO-30 resampled to 25 m over Val Venosta (Italy). The comparison scripts can be shared.
- Dominant language
- Rust
- Stars
- 1.9k
- Forks
- 268
- Avg merge
- 3h 37m
- Merged PRs (30d)
- 797
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from opengeos/RustGIS
-
[Feature]: Interface themes as JSON files, with an interface scalePossibly taken @Wolren claimed this today. Open
Difficulty 5/5 Over a week Newbie friendliness 1/100
Maintainers usually reply within 1 day
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
opengeos/RustGIS#1144 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
[Bug]: Clip and Select by Location compare every feature with every overlay polygon: minutes where an indexed tool takes secondsPossibly taken @Mavrick-F claimed this today. Openbug
opengeos/RustGIS#1142 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
-
unconfirmed possible issue
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
All issues in opengeos/RustGIS
Similar issues
-
Add a just recipe that runs the workflow linters locallyPossibly taken @sgamelin claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
good first issue security
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Status bar: a progress line that keeps the same text (import at 0%) ages out after 8 s and blinksOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
transit-audio/transit#216 ·
-
area: effects devices enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
suhina-daw/suhina-daw#1060 ·
Maintainers usually reply within 1 day