Opened 16 years ago
Closed 16 years ago
#2414 closed defect (fixed)
warp_4 fails
| Reported by: | Even Rouault | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | GDAL_Raster | Version: | unspecified |
| Severity: | normal | Keywords: | warp |
| Cc: | dron, Mateusz Łoskot |
Description
The warp_4 fails on epimetheus, and on my personal PC (Linux i386). On my machine, I observe 4 horizontal bands in the image (see attached picture). I think it is related to the value of the BlockYSize in the utmsmall_cubicspline.vrt file, because if I put 512 instead of 128, warp_4 succeeds. However, Andrey has confirmed that the test succeeds on his PC (Linux i386 too). So, what happens ???
Side node, warp.py doesn't run on telascience and szekerest slave bots, because of the unavailability of the numeric package.
Attachments (1)
Change History (6)
by , 16 years ago
| Attachment: | utmsmall_cubicspline.vrt.tif added |
|---|
comment:1 by , 16 years ago
| Cc: | added |
|---|
comment:2 by , 16 years ago
In r15108 I've introduced a method in gdaltest.py, compare_ds, that was used previously by utilities/test_gdalwarp.py. So warp.py now doesn't need gdalnumeric.
comment:3 by , 16 years ago
Note for Andrey related to his comment in #2537 : the bug was reproduced on all GDAL buildbot slaves before being disabled.
comment:5 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
The mystery is solved! I had a fix for this problem locally in my working tree for a long time, but for some unknown reason totally forgot to check it in. That is why it was not reproducible on my system until I decided to compare my sources with trunk. r15243 should fix it.
Result of gdal_translate on utmsmall_cubicspline.vrt