I am updating an ArcGIS toolbox from ArcGIS 9.3 to ArcGIS 10.3. The tools "gp.PathDistance_sa" and "arcpy.sa.PathDistance" produce different outputs using the same input settings and input layers. Is there any documentation for changes to this tool? Any idea regarding the cause of the discrepancy?
I read the help section for both tools, and did not see any indication that the algorithm had changed. I was also unsuccessful in finding anything with Google, nor through consultation with our local GIS center. However, I am getting differences in output of around 0.5, which in the system I'm working in, is high enough that it's worth trying to find an explanation for the discrepancy.
and to clarify, you are doing this with the exact same files, the same environment settings (in the Environments section for the tool ie extent, cell size, snap raster etc, not the general settings for arc*)?
To the best of my abilities, I am doing everything the same.
We are using the exact same input files. If I replace the Viewshed and PathDistance outputs from ArcGis 10.3 with the Arc 9.3 versions, I can get the exact same final output out to ~3 to 5 decimal places. See https://community.esri.com/message/586624?et=watches.email.thread#586624 for the similar problem with the viewshed tool.
For environments, we've replaced:
### Set general parameters for rasters
dscRD = gp.Describe(eucdist_ft)
RasterExtent = dscRD.Extent
CellSize = dscRD.MeanCellHeight
with:
# Set general parameters for rasters
dscRD = arcpy.Describe(eucdist_ft)
RasterExtent = dscRD.Extent
CellSize = dscRD.MeanCellHeight
and in the applicable tools we have replaced:
### Environment settings
##gp.Extent = RasterExtent
##gp.CellSize = CellSize
with:
arcpy.env.extent = RasterExtent
arcpy.env.cellSize = CellSize
We had not set snap raster but I just added it in both the 9.3 code and the 10.3 code, and the major differences between versions persist.
differences appear near the edges of the features... which is why I asked if a snap raster was used. but now you state that the difference was 0.5 but relative to what? And is there anywhere in the process that integer division could be going on? So 0.5 occurs where? 0.5 relative to what? and integer division would be my questions if cell size extent and snap raster were all equal to rule out many common problems. In cases like this, I would be inclined to construct a standard surface to test both against something that would have a known outcome.
The standard surface suggestion is a good one, and I may have to go that route.
I think the problem is with the PathDistance tool itself, and I was hoping for a link to existing documentation that would just tell me what the difference is. Alternatively, if I could look at the tools' source code, that may help me answer the question as well.
It's also possible I've just mis-translated something in the conversion from 9.3 to 10.3. Here is an example of one of the two instances of the PathDistance calculation in my code:
### Calculate path distance around buffered source point (with vegetation loss)
##pathdist2 = "C:/SPreAD-GIS/intermediate/veg/pathdist2"
##gp.PathDistance_sa(sound_src_veg, pathdist2, veg_cost, eucdist_z, "", "BINARY 1 45", "", "BINARY 1 -30 30", "")
# Calculate path distance around buffered source point (with vegetation loss)
pathdist2 = "C:/SPreAD-GIS/intermediate/veg/pathdist2"
pathDist = arcpy.sa.PathDistance(sound_src_veg, veg_cost, eucdist_z, "", "BINARY 1 45", "", "BINARY 1 -30 30")
pathDist.save(pathdist2)
sound_src_veg is a buffer (30.48 m) around a source point, pathdist2 is the output raster, veg_cost is a cost surface, eucdist_z is the surface raster. I'm not sure if the horizontal and vertical factors matter, given that we don't include a horizontal or vertical cost raster in the calculation. The surface raster varies by ~4000 over the region of interest, the cost raster ranges from 1 to 1.0501 (but the error is also present with no cost raster).
Sorry about the confusion regarding 0.5. I included that to give a sense of the magnitude of the tool output error. I'm modeling sound propagation, so it's 0.5 dB. The error is not constant, and is greater the farther from the source point (around 0.1 - 0.2 close to the source to closer to 0.5 at a distance of around 1 km). I don't think integer division is the problem. Differences in rounding might explain it, but I feel like the differences are large for that.
The formulae for both path and cost distance are the same, the former accounts for the vertical component. When looking at the formula and the calculation of diagonals, they give a division of 2... but don't state whether it is a float(2) or what. The only thing that could cause integer division is if the terms on the top of the equation(s) are integers and the divisor is int(2). But on a lark... I would float the costs