# Can I avoid decimal conversion calling CostDistance

Our client asked us to incorporate blockages and delays for movement of boats and ships on the local waterways. In our one process we are creating polygons of the distance a boat can move at top speed for up to 90 minutes.

The change required us to look at several things and we decided to set the raster to a time-based seconds per meter. In our test sample I have a point located on the waterway. I have time zones established for how far a boat will move with no slowdowns.

``````ie.  Boat speed = 40 knots
@15 minutes  10 nm
@30 minutes  20 nm
@45 minutes  30 nm
@60 minutes  40 nm
@90 minutes  60 nm
To define the seconds/meter we compute 40 * 1.94384449 rounded and converted to integer.
``````

this yields a default raster value of 78 which is the number of seconds it takes for the boat to move one meter. And when we convert nautical miles to meters the maximum distance a boat can travel at full speed is 8667360 meters.

All of these numbers are within a decent realm for storing as integer values in a cost raster, yet when I call CostDistance() it takes 33 hours to run and the result shows the 8667360 in scientific notation. (which means it is being stored as floating point in the raster)

So my question is What can I do to force CostDistance to remain integer so it will not run like a dog and take 33 hours?

• Is it just me, or does the math seem...odd? For 15 min = 10 nm, I get 20.58 m / sec or 0.0458 seconds to travel a meter. – mkennedy Mar 11 '14 at 17:59
• Yes the math seems odd. But I've googled several sites for converting knots to seconds/meter and all list it as speed * 1.94384449. 1 knot = 0.514444 m/s and 1/0.5144444 = 1.94384449. – SASS_Shooter Mar 14 '14 at 17:09
• Divide, not multiple, I think! 1 knot = 0.514444 m/s, 40 knots = 20.57776 m/s. Inverse, 0.048596 s/m. – mkennedy Mar 14 '14 at 17:20
• DOH -- okay so it is 1 / (speed*0.514444) – SASS_Shooter Mar 16 '14 at 13:12

``````The output raster is of floating point type.