Point to Raster with input field of type Double produces integer raster

[isburns]

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.

[DanPatterson_Retired]

what is your value_field and what cell_assignment did you use?

Point to Raster—Help | ArcGIS for Desktop 

[isburns]

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.

[DanPatterson_Retired]

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

[isburns]

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.

1. Run Raster to Point with a floating point raster and save the output as a shapefile. My floating point raster had values of xxx.xxxxxx. Also worth noting, if you save the output as a feature class in a file geodatabase, the grid_code field will be a float, and in the shapefile it is a double.
2. Add a float field to the output shapefile and calculate it from the double field. Here is one opportunity for a loss of precision (xxx.xxxxxx to xxx.xxx).
3. Run Point to Raster with the double field as the value field. The output is an integer raster, and consequently results in loss of precision.
4. Run Point to Raster with the float field as the value field. The output is a floating point raster. You haven't lost precision at this step per se, but you lost precision at step 2 so the output raster has less precision than what you started with.

[DanPatterson_Retired]

Cant test now, but I am familiar with the whole float/double issue.  So 3 scenarios

• shapefile with the double field produces .... integer raster
• featureclass with double field produces .... ???
• featureclass with float field produces ... ??? 

Could you fill in the .... portions to confirm, and I will look at another option

[isburns]

• shapefile with double field produces 32-bit signed integer raster
• shapefile with float field produces 32-bit floating point raster
• file gdb feature class with double field produces 64-bit double precision raster
• file gdb feature class with float field produces 32-bit floating point raster

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.

1. Execute Raster to Point and save as a shapefile;
2. Convert the shapefile to a file gdb feature class; and
3. Use the file gdb feature class as input to Point to Raster.

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.

[DanPatterson_Retired]

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.

Addendum

I did post a blog explaining the principle /blogs/dan_patterson/2016/04/30/masks-nodata-rasters-arrays 

[SteveLynch]

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.

-Steve