nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Planform Curvature values much too high

stanaforth

I am having trouble producing a planform curvature output. I'm unsure what units to use and the spatial analysis documentation seems sketchy. The values should be >-0.1 (convex), -0.1 to -0.4 (planar), and >-o.4 (concave). My values are much larger as shown in an attachment.

The intent is to employ the technique used in "Modeling Steep Terrain Harvesting Risks Using GIS" also attached.

Any guesses?

Stan Hopkins

Plan form curvature.doc

Modeling Steep Terrain Harvesting using GIS.pdf

Trouver plus de publications taguées avec

Accepted answers

All comments

MeganSchofield

I was wondering if you could help me.

I have curvature values of 4.6967e+012 --> -4.88592e+012, and once exported give mean values of -53136000614 to 73871998976
, which are obviously too high.

I really don't know what I am doing wrong. I (think I) have attached a picture of it for you to visualise better. Thanks.

help.docx

Anonymous User

Original User: stanhopkins

Not sure of some of the problems expressed by others since I started the thread, but I have perhaps found a pragmatic solution to my latest problem (recommended values not "too high" for planar, concave and convex curvatures any longer, but not agreeing with the topography that I can see in the map).

I ignored the values in the attached "Steep Inclines" article and jiggered the planar, concave and convex values until they agreed with the landscape. Works like a charm.

Stan Hopkins

AndrewStauffer1

Thanks Bill!

I have identified the problem thanks to you. I downloaded my data from the USGS's The National Map and my study area was broken into 6 DEM pieces. When I projected the 6 pieces, I now noticed that the projection had created a 1 cell wide gap in some places that persisted when the pieces were merged together. This was throwing the curvature tool off.

Thanks for your input.

Anonymous User

Original User: whuber

The largest value of 10^38 is close to the limits of single precision floats, Andrew. This suggests that (a) NoData values were present in the original grid, (b) they were coded as values with extremely large sizes, (c) for whatever reason they were not recognized as NoData during the import procedure, and (d) these values were (therefore) treated as genuine numbers during the resampling process that necessarily accompanies reprojection.

If this diagnosis is correct, the fix is to return to the original grid, force all out-of-range data (say, any elevations less than -1000 m or more than 10,000 m) to be true NoData values (use SetNull), and then reproject and recompute the curvature.

AndrewStauffer1

I am still having some difficulty with this output. I downloaded a 10m DEM from USGS's TNM and projected it to UTM zone 18N. I opened a new ArcMap project and opened the DEM. I ran the curvature tool and got the following outputs:

Curvature: +/- 1.#INF
Profile: 3.40282e+038 - 1.17549e-038
Plan: same as Profile Curvature

I'm not sure why this isn't working. I had the same thing occur in ArcInfo 9.3 and ArcView 10. Any insights? I tried to adjust the z value that delivered the same results, and this way seems like more of a cosmetic fix anyway.

Also, in Arc 10, ArcMap crashes at 99%, but creates an unprojected curvature raster. Just wanted to know if anyone was experiencing this or if my Arc10 needs reinstalled.

Thanks

Anonymous User

Original User: stanhopkins

Sorry for the delay - family matters.

Thanks to Bill Huber and Dan Peterson - projection to UTM and a Z value of 0.01 gives reasonable figures.

WilliamHuber

Yes, but not a billion!

I think you're on the low side, Stan: there are about 10^5 meters per degree and curvature is a squared unit, so failing to project your data will introduce an error of about (10^5)^2 = 10^10 = ten billion. Multiply that by 100 and you're up to an even trillion ;-). Anyway, whenever topographic calculations are off by this many orders of magnitude, it's invariably due to keeping raster data in decimal degrees instead of projecting them: that insight is what prompted Dan's initial response.

Anonymous User

Original User: stanhopkins

Stan
If the coordinates are in decimal degrees, the elevation will not be (doesn't make sense, elevation is either in meters or feet). This is what I was questioning. since you indicate that the coordinates are in decimal degrees, the file(s) should be projected so that the coordinates ( X and Y) are in the same units as elevation ( Z ) whether it be meters or feet. Bill indicated that the software (arbitrarily??) multiplies the resultant by 100, essentially expressing values as a percentage. Try projecting the data to a suitable projection, redo the analysis and see if the resultant makes more sense (accounting for the scaling)

I'm sorry, I was careless in my reply. Both are in meters.

DanPatterson_Retired

Stan
If the coordinates are in decimal degrees, the elevation will not be (doesn't make sense, elevation is either in meters or feet). This is what I was questioning. since you indicate that the coordinates are in decimal degrees, the file(s) should be projected so that the coordinates ( X and Y) are in the same units as elevation ( Z ) whether it be meters or feet. Bill indicated that the software (arbitrarily??) multiplies the resultant by 100, essentially expressing values as a percentage. Try projecting the data to a suitable projection, redo the analysis and see if the resultant makes more sense (accounting for the scaling)

stanaforth

Curvature values are artificially multiplied by 100, Stan: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=How%20Curvature%20works .

Yes, but not a billion!

Anonymous User

Original User: stanhopkins

Dan_Patterson;35779 wrote:
Are the coordinates and the elevations all in the same units? ie meters or feet
Or are the coordinates in decimal degrees? I would suspect that you must be working with projected data and x,y and z must all be the same units[/QUOTE

Both the map and the elevation file are in decimal degrees and both are unprojected (GCS_North_American_1983)

WilliamHuber

The values should be >-0.1 (convex), -0.1 to -0.4 (planar), and >-o.4 (concave). My values are much larger as shown in an attachment.

These thresholds are unusual. Curvatures always, in my experience, change sign to differentiate between some form of local convexity and local concavity, with zero always corresponding to flat.

Anonymous User

Original User: whuber

Grief...now why would they do that, without giving the option to the user to omit the scaling

I have always supposed this scaling was selected because for "typical" earth elevation datasets the sizes of the resulting values are typically not huge (e.g., most of them 10^2 or larger) or tiny (e.g., most of them 10^-2 or smaller).

Watch out for the help. The pages describing curvature exhibit both the best and worst of ESRI documentation: they are excellent in clearly displaying the formulas used (which cuts through a lot of potential confusion) and horrible because many of the English statements made about the formulas are incorrect!

DanPatterson_Retired

Grief...now why would they do that, without giving the option to the user to omit the scaling

Anonymous User

Original User: whuber

Curvature values are artificially multiplied by 100, Stan: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=How%20Curvature%20works .

DanPatterson_Retired

Are the coordinates and the elevations all in the same units? ie meters or feet
Or are the coordinates in decimal degrees? I would suspect that you must be working with projected data and x,y and z must all be the same units

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.