Problem with DEM and Path Distance

[MargaretBrown_Vega]

Hi all,

I am trying to calculate path distance, using a vertical factor table (created by Nico Tripcevich based on Tobler's hiking function, discussed here http://forums.esri.com/Thread.asp?c=93&f=995&t=138683, among other places).

I created a DEM from SRTM version 4. When I calculate path distance using the vertical factor table, then generate contours, I get fairly evenly-spaced lines that look more like Euclidean distances. This is mountainous terrain. One should not be able to travel as far in the same amount of time when climbing a mountain. In fact, Euclidean distance contours seem to be further from the source point, even in areas where there are mountains that I know take two to three hours to climb!

In the past I've calculated path distance before using another DEM (an earlier version of SRTM). To try and diagnose the problem I snagged this earlier DEM, and calculated path distance from the same point feature on both DEM's for comparison. My problem is best illustrated in the two attached graphics. In the first graphic, the red contour lines represent what was generated with the earlier DEM, and is what I expect. The blue contours are my problem: that is what is produced doing the exact same calculation with this new DEM I've created. I am going mad trying to figure out what the problem is with this second DEM.

I've been able to calculate slope with this newer DEM (see attached figure 2), as well as some other compound indices. But there appears to be something wrong with the DEM. Other analyses have looked okay, but the path distance does not. Just to illustrate the point further the image shows slope from the second, problematic, DEM, and the evenly spaced path distance contours (which make no sense given the terrain).

I compared the two DEM's, which are of the same geographic area, and there seems to be a big difference in elevation (600 m).

My plan is to go back and use the older DEM. But, I would like to know what the problem is with the newer DEM (assuming that's what it is). Any suggestions or feedback would be much, much appreciated!

Sincerely,
Margaret

[LauraGriffin]

I was having the same problem for my large raster DEM.

Here's what DIDN'T work:
-ArcGIS 10.0, without any service packs
-ArcGIS 10.0, with service pack 1
-ArcGIS 10.1, without any service packs

Here's what DID work:
-ArcGIS 10.1, with service pack 1

For me, changing the format of my raster to a 32-bit GRID file and increasing the number of unique raster values to 2 million didn't help.  The only thing that worked was using 10.1 in combination with Sp1; with this combination, even the default values worked with a 16-bit signed raster.

Hope this helps.

[Anonymous User]

Original User: togrady

I have been facing the same problem for some time, and in my case it happened to be an issue with the 10.1 version. Solved after installing Service Pack 1.

This worked for me as well.  I am very relieved.  Thank you for posting.

[BethScaffidi]

Hi all,

It's been awhile since I have tried to do this analysis. I have a call into ESRI for help, but in the meantime I followed the steps below to get Steve's workflow above to work in 10.3.1. After doing these things, I still wasn't able to get anything other than the isotropic spiderwebs:

1) modified Nico's ToblerAway table to include these field names: VRMA and VF from left to right. I thought it looked like the concentric spiderweb wasn't reading the table, so made that change.

2) set DEM as the surface raster

3) set the maximum raster processing to 500,000 (area is large, from Huari to Moquegua for Andeanists)

4) saved my output anisohrs to the default .gdb where it wanted to go rather than putting in a new location

Also, make sure you've installed the background geoprocessor after you installed ArcMap. I encountered problems with all kinds of heavy-duty raster analysis before adding that step to my installs. Also, reading and writing to different locations (not both networked locations) helps me generally run processes faster. This isn't as big of a deal in ArcGIS Pro, since the database was built in a different way.

I was able to generate the anisotropic layer with Nico's Tobler-derived table and then used that layer to run cost paths back in desktop.

Good luck!

[BrooksLawler]

Hi All,

I am definitely no expert in ArcMap and could really use some help.

I have been working on calculating the cost to travel from raw material toolstone sources in Interior, Alaska using Tobler's Hiking Function. I followed Kaitlin Yanchar's tutorial: ArcGIS Tutorial: Tobler’s Hiking Function (Anisotropic Distance) | Kaitlin Yanchar, MA, RPA in a version of ArcMap 10. I used a 100m resolution DEM, 32 bit floating point raster. I clipped the DEM to only include the analysis extent which is about a 46,000 square mile area, and then followed the steps of the tutorial. Slope is the only friction surface I used. The cost raster and resulting values of the cost raster appear to be anisotropic and correct in relation to one another, but I am having a problem similar to Mathew Schmidtlein. My values are not underestimated, they seem to be significantly overestimated, such that the time it would take to travel several hundred miles, when the cost is converted from minutes to years, would take several years. I followed the tutorial twice and came up with the same values. There is steep terrain in the area, but I looked at the slope values and there are none that are over 70 degrees, so I don't think ArcMap is getting hung up on terrain that may be impossible to traverse. Does anyone have any ideas why I may be getting such huge cost values? Is it possible that the values of the cost raster are not in minutes?

Thank you for your help,

Brooks

[netafriedman]

Hi,

Don't have much to add.

I seem to have the same problem only with ArcMap 10.5

Did anyone find a solution?

Thanks