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

[Anonymous User]

Original User: mybvega

I found the problem, and it does not appear to have been the DEM.

I was following a protocol for calculating path distance that didn't entail including a cost raster. Rather, I just used the DEM. For some reason, this does not now work. I took my slope raster calculated from my DEM and set that as my cost raster, and my DEM as the surface raster. This worked. Problem solved. An omission of a necessary input. Does anyone know why I would have been able to calculate it before without the slope raster input (simply using the elevation field from the DEM)?

[StevenWernke]

I am having a similar problem with the exact same data types (I am also using Nico's Tobler-derived vertical factor tables, and conferred with him personally on it; I am sure the tables are not the issue).

To be clear, here is exactly how I ran it using the Path distance tool:

Spatial Analyst Tools > Distance > Path Distance...
a. Input: Sites (my source point data--one point selected)
b. Output: aniso_hrs1 
c. Input cost raster (optional):<blank>
d. Input surface: colca_clip (my clipped 30m DEM)
e. Maximum distance (optional):<blank>
f. Output backlink raster (optional): aniso1_bklk
g. Vertical factor parameters (optional): Input Vertical Raster: colca_clip, Vertical factor (optional): Table, using Nico's "Tobler_away.txt"
h. "Environments...">  "Processing Extent..." > Set the Extent to "Same as Display"

The "good" news is that I can get it to run using the above, but ONLY if it is zoomed into a small area.  Beyond a certain extent (not a very large one at that), it won't work anymore, even restricting the processing extent to Same as Display.  If I use the extent of the DEM as the processing extent, it will just return a Euclidian distance grid, ignoring the DEM.

FYI, the DEM must be 32 bit floating point, with square pixels for it to work.  That might be your problem.  Mine, however, has to do with the extent. 

Please ESRI people, throw us a bone.

[Anonymous User]

Original User: rwhitlow

Steve,

I think it's a problem with the raster's cell count, not the extent. I ran into the same issue and was able to fix it by resampling the raster to a larger cell size. I don't know the ceiling for Path Distance, but I was able to roughly bracket the column x row measurements. A 388 x 484 (~188k cell count) raster works, a 542 x 677 (~367k) raster does not. I may keep playing with this, and let you know if I find the magic number.

- Ray Whitlow

[MathewSchmidtlein]

Any news on this?  I'm trying to figure out some issues with an analysis I'm running for a moderately sized study area, but with 1 meter pixels.  It is an area of pretty low relief, but we are getting what seem to be dramatically low estimates for pedestrian travel times.  It worked, however, before I upgraded to 10.  Were there changes in the Path Distance tool at the 10 release that are causing this issue?

[MathewSchmidtlein]

In case this is helpful to anyone:  I have been using Path Distance to model pedestrian evacuations, using reclassified landcover as a cost surface, and elevation as the surface layer and vertical factor, all with 1 meter resolution data.  When I was running it with ArcGIS Desktop 10, it would run for about 24 hours, and result in dramatic underestimates of travel times.  I still had my copies of 9.3.1, so I removed 10 reinstalled that, and the whole process took about an hour, and is returning more reasonable results.  So I am suspecting the issue here is something to do with changes made at the 10 release.  I like 10 overall, but Path Distance doesn't seem to work well in it.

[Anonymous User]

Original User: dcontre

I am having a similar problem (and did about a year ago as well).  Last time, I was eventually able to solve the problem by converting my input point to a raster, and by making sure all raster inputs were in GRID format (which does not I think conform to Steve's suggestion of 32-bit floating point, but worked).  I also had to eliminate hidden spaces in the file paths to which the Path Distance tool was writing (running VMWare on a Mac, the default file path includes a space). 
It took addressing all of those issues to get an result that didn't ignore the input raster and just produce a Euclidean distance (the same pattern that Margaret illustrates above).  Coupled with the various suggestions here, this makes me think that a variety of errors lead the Path Distance tool to produce Euclidean results.  I did eventually get real results, though - and with a sizable underlying raster (23896 x 24107), 16 bit continuous signed integer.
At any rate, I am now stumped by the same problem again.  I am trying to calculate Path Distance using a SRTM 90m pixel raster as the input.  I've converted my origin point from feature to raster, double-checked file paths and raster formats, and tried with both UTM and Lambert Conformal Conic projections.  I've even gone back to my old data (different region entirely), which I ran successfully last Feb., and tried to re-run those.  The output is invariably a concentric spider-web.  Does anyone have any suggestions?  I notice the last post here was a few months ago - has anyone figured out the root problem and/or a solution?

Many thanks,

Dan

[DavidRedhouse]

I am having a similar problem (and did about a year ago as well).  Last time, I was eventually able to solve the problem by converting my input point to a raster, and by making sure all raster inputs were in GRID format (which does not I think conform to Steve's suggestion of 32-bit floating point, but worked).  I also had to eliminate hidden spaces in the file paths to which the Path Distance tool was writing (running VMWare on a Mac, the default file path includes a space). 
It took addressing all of those issues to get an result that didn't ignore the input raster and just produce a Euclidean distance (the same pattern that Margaret illustrates above).  Coupled with the various suggestions here, this makes me think that a variety of errors lead the Path Distance tool to produce Euclidean results.  I did eventually get real results, though - and with a sizable underlying raster (23896 x 24107), 16 bit continuous signed integer.
At any rate, I am now stumped by the same problem again.  I am trying to calculate Path Distance using a SRTM 90m pixel raster as the input.  I've converted my origin point from feature to raster, double-checked file paths and raster formats, and tried with both UTM and Lambert Conformal Conic projections.  I've even gone back to my old data (different region entirely), which I ran successfully last Feb., and tried to re-run those.  The output is invariably a concentric spider-web.  Does anyone have any suggestions?  I notice the last post here was a few months ago - has anyone figured out the root problem and/or a solution?

Many thanks,

Dan

I had this problem last week. It nearly reduced me to tears. It occurred in ArcGIS 9.2 (Desktop and Workstation) and ArcGIS 10 (Desktop and Workstation). In the end I got it working by converting my DEM to a 32-bit Float, then exporting that as a GRID outside of my File Geodatabase, and then using a Shapefile to hold the start points. I stored everything in C:\TEMP and my filenames were all shorter than 8 characters and used only letters in them. Also I waved a rubber chicken over the computer three times before pressing OK.

HTH

[Anonymous User]

Original User: lkellett

Did anyone figure out the path distance problem in ArcGIS10, specifically in using a SRTM DEM? LK

[DanielBecker]

Ohh.. same problem here. I work on my geography diploma thesis which is about, well.. prehistoric sites and distance/site catchment analysis around caves (and i have to work with arcgis).

Now i discovered the toblerAway-table and was very happy that this could be a nice solution, but it only works if i zoom in to a very small extent (while using processing-extent: same as display).

In other cases i also get the Euclidean Distance pattern in the resulting cost raster. 😞