In ArcGIS 10.4.1 and earlier versions (tested back to 10.2), executing the Point to Raster tool with the value field of the input set to a double field results in an integer raster output. When executing Point to Raster with the value field of the input set to a float field, the raster becomes a floating point raster. The documentation for Point to Raster says
The input field type determines the type of output raster. If the field is integer, the output raster will be integer; if it is floating point, the output will be floating point.
I tested a floating point field input and it does result in a 32-bit floating point raster as expected, but calculating a floating point field from a double field just to get the 32-bit floating point raster output results in a forced loss of precision since the max precision of a floating point field is 6. The assumption and expected behavior is that using a double field type will result in a floating point raster without loss of precision, and NOT an integer raster.
The value field was a double and the cell assignment was most frequent. An easy demonstration of how Point to Raster can result in a loss of a precision is to execute Raster to Point on a floating point raster followed by executing Point to Raster on the output of Raster to Point. Provided you set the snap raster and processing extent the same, the result should be identical to the input, but it's not.
Also, you haven't specified the source of the points... as in a previous thread went unresolved, if your inputs are not regular points, then that may be the issue. Xander Bakker suggested using
LAS Dataset To Raster—Help | ArcGIS for Desktop if the inputs are from a las dataset. You didn't comment on that thread so I am not sure if this is your case too since I can't find any reported issues that have a past or current case number
The points are regular, they came from the Raster to Point tool.
Even if they are not regular however, the documentation does not describe this. The point is that the tool behaves in an unexpected way from what the documentation describes. Granted, it doesn't actually describe using a double field as input, but a reasonable expectation for this is for it to create a floating point raster and NOT an integer raster. I wouldn't call think this is an omission from the documentation, I'd call it a bug.
If you'd like to see if you can reproduce this, here are some steps.
Cant test now, but I am familiar with the whole float/double issue. So 3 scenarios
Could you fill in the .... portions to confirm, and I will look at another option
So shapefiles are part of the issue with this workflow. So while the following workflow works around the problem, there is still a problem with the tool itself.
However, to confound the issue, with the additional troubleshooting I used a much smaller area to reduce the processing time, and the first time it gave me a 32-bit signed integer raster when the input was a shapefile with double field, but at some point the tool started giving me a floating point raster under identical conditions (rerunning the tool with the same exact inputs using the Results window). On the larger area, it consistently gives me a 32-bit signed integer raster using the shapefile with double field however.
Wow... your last paragraph really should be looked by the support people. It would be worthwhile sending off this for investigation flagging this thread. If it is indeed an issue, then people need to know... if it has something to do with the data, then that needs to be done as well.
My normal procedure is to convert a point shapefile/featureclass to a numpy array using the shape's X, Y coordinates then the appropriate Z (FeatureclassToNumPyArray).
This produces a structured array with either a uniform or mixed datatype depending on whether Z is integer, float or double. If I just need to work with the 'raster' then I am done. If I want to work with in convention raster format, Then I produce a sparse array with a convention X and Y axis and Z being the point value. From there I can either work with in that form, or if I really need to see it, I can view it in MatPlotLib OR, if I want to bring it backinto arcmap, then I use NumPyArrayToRaster.
So your workaround and warning should be noted, but my standard work procedure is an alternate.
Keep this thread posted should you get this forwarded and get a case number.
I did post a blog explaining the principle /blogs/dan_patterson/2016/04/30/masks-nodata-rasters-arrays
It also depends on the values. It you have a double field and the values don't have decimals it'll create an integer raster. ESRI grid format can't accommodate double, which means the output raster must support double, i.e 64 bit.