Shift Tool destination file issue

[AdamBorczyk]

The problem is that when I use Shift tool on a raster, it doesn't get shifted no matter what distance values do I input. This happens when I set Output Raster Dataset to my custom location (inside Folder Connections). If I leave it default (Default.gdb), it gets moved properly. Why is it so? I would really like to avoid saving it do default GDB and then opening it and saving somewhere else.

The raster is RGB composition straight from Landsat bands from Earth Explorer.

I use ArcMap 10.4.1.5686, I have background geoprocessing disabled.

Geoprocessing results windows shows everything is fine.

The tool is inside Data Management Tools -> Projections and Transformations -> Raster.

Any help will be appreciated.

Best regards,

Adam

[DanPatterson_Retired]

The shift tool help indicates that...

You can save your output to BIL, BIP, BMP, BSQ, DAT, Esri Grid , GIF, IMG, JPEG, JPEG 2000, PNG, TIFF, or any geodatabase raster dataset.When storing your raster dataset to a JPEG file, a JPEG 2000 file, or a geodatabase, you can specify a Compression Type and Compression Quality within the Environments.

can you confirm your formats and check you extents in its properties. Of course, you are shifting the file in the same coordinates as they are in (ie meters coordinates, meters shif)

[AdamBorczyk]

I'm not sure if I was understood correctly. I mean that:

having a file "file.tif" and saving to C:\Users\adam\Documents\ArcGIS\Default.gdb\cfile_shift works

but

having a file "file.tif" and saving to eg. D:\images\file_shift.tif does not work

also

having a file "file.tif" and saving to eg. D:\images\file_shift does not work either

(note differences in extensions tried here - manipulation between .tif and ESRI grid doesn't help, so format is not an issue)

Custom output localisation leaves me with a new file "file_shift" or "file_shift.tif", that has same position as the original one.

[DanPatterson_Retired]

perhaps the file is shifted but not using a world file which would account for it working inside of a gdb, but not outside.  It also might be a good idea to check the file extents before and after the shift to see if it has moved.  Barring that, even a tfw doesn't contain the coordinate system that is being used, just the coordinate space, check to see how the coordinate system is 'defined'

[AdamBorczyk]

Thank you for this suggestion. However, raster properties and world file of an image both show same and correct (expected) value. What is more, after setting very large numbers into X and Y offset field, the image actually gets moved, or I would rather say: very big black box with no image inside gets moved by X and Y.

But here comes good news - after trial and error check, I discovered that the problem was indirectly caused by setting custom Parallel Processing in Environment Settings. I had it set to 100% to force full CPU usage, but after removing it and leaving default, the problem is gone. Shift tool works well again.

Is it a bug I should report or this kind of problem with Parallel Processing is an expected behavior?

[DanPatterson_Retired]

Report it... this took too much time from everyone, and there is no documentation parallel processing can cause these issues  And I would leave parallel processing aside until you are working in a full 64 bit environment (not ArcMap related implementations, try to see it works better in PRO)

Thanks for the update Adam