Ticket #407 (closed Defect: fixed)
Predict GLM and Predict GAM tools fail with RuntimeError: This tool was unable to project ... to the coordinate system of the template raster and obtain a projected raster with an extent that matched that of the template raster.
|Reported by:||jjr8||Owned by:||jjr8|
|Component:||Tools - Statistics||Version:|
The full error message looks something like this:
RuntimeError: This tool was unable to project E:\rhema\data\distance0504\dis2any_0504_Clip_Clip.img to the coordinate system of the template raster and obtain a projected raster with an extent that matched that of the template raster. The extent of the projected raster was -4027118.88008202 942851.969307701 -3160118.88008202 1517851.9693077, while the extent of the template raster is -4028118.88008202 941851.969307701 -3161118.88008202 1516851.9693077. (The extent values are ordered LEFT, BOTTOM, RIGHT, TOP.) If the extent of the template is larger than the projected raster, it may mean that the template is too large (i.e. that the predictor raster does not cover the entire extent of the template). In that case, try reducing the extent of the template. If that is not the problem, try projecting the predictor raster yourself prior to providing it to this tool, such that its coordinate system, cell size, and extent match that of the template.
The tool checks the coordinate systems, cell sizes, and extents of all predictor rasters to make sure they match the template raster. (If you don't explicitly provide a template raster, the first predictor raster will be used as the template.) So long as the template raster has a smaller extent on all four sides than all of the other rasters, the tool is supposed to work automatically, projecting and/or clipping the predictors so they exactly match the template. When the tool determines this needs to be done for a predictor raster, it makes one attempt to project and/or clip and then checks the output extent on all four sides. Because computers do not store an infinite number of decimal places for floating point numbers, ArcGIS can exhibit a rounding error that causes the extent to be "off" by one cell on any or all of the four sides. For each side that is off, the tool adds or subtracts a bit and then tries the project/clip a second time. After this second attempt, the raster should be perfectly aligned, but the tool checks again to be sure. If it is not, the tool throws up its hands and reports the error message.
Here's an example where it failed:
LEFT BOTTOM RIGHT TOP template (-4033498.68196839 941537.372199999 -3160498.68196839 1517537.3722) attempt1 (-4034498.68196839 940537.372199999 -3160498.68196839 1518537.3722) attempt2 (-4033498.68196839 942537.372199999 -3160498.68196839 1517537.3722)
You can see that on attempt 1, only the right extent was correct. So the tool adjusted the left, bottom, and top and tried again. This fixed the left and top, but the bottom ended up overshooting. In the first attempt it was 1 cell below the template; in the second it was one cell above.
The problem is that the tool was adjusting by a full cell: 1000 meters in this case. It turns out that adjusting by a full cell often works, but not always. No doubt I was thinking "if it's off by one cell, just add or subtract one cell". Well the nature of this rounding is such that sometimes it rounds up and sometimes it rounds down. When I added a full cell, it switched from rounding down to rounding up.
The solution is for the tool to not add a full cell. I changed it to add only half a cell and it worked.
This fix will first appear in MGET 0.8a8.