# Why is my terrain model spikey?

Converted a DEM file to point cloud and created mesh by Delaunay mesh. The terrain’s general shape appears to be correct, but why is it spikey all over? Attached csv.
PTCLD_XYZ.csv (2.0 MB)

Hi Salonee -

It looks like you’ve got some z-scaling issue in that data:

min = 79.890,26.276,105.000
max = 80.715,26.655,144.000
dimensions = 0.825, 0.379, 39.000 millimeters

When I import the points, this is how it looks here:

Perhaps the original DWM file doesn’t have that issue? You can import that directly by using a plug-in such as Heron.
-wim

Yes, that’s generally it. It’s actually an XY scaling problem but the result looks like a Z scaling problem.

If the points were from an ASCII-Grid file, the grid can be specified in either absolute distance units (generally meters) or in arc-seconds of the earth’s circumference. It’s usually easy to tell, the meter-distance values are usually largish numbers that have some easily-recognized incremental distance between them and have perhaps max 3 places after the decimal; the angle based increments are much smaller and have lots of places after the decimal.

These are my notes from my ASCII Grid importer:

MULTIPLIER because cellsize could be in degrees, not meters!
1 degree earth's circumference at equator is about 111.319 km (111319) m;
Pole to pole it's only about 111.133 m. Basis for nautical mile (1 arc minute)
is 1,852 m or a multiplier of 111120 m.
Try to autodetect this condition: if cell size is less than 0.02
then likely the cell size is degrees...
3 arc seconds will show a value of 0.00833333 as a cell size
1 arc second will have a value of  0.00277777 as a cell size
However - result may still not be correct -
as arc second files are ##spherical projections!!##

Here is what your data looks like:

You can see that the points are organized in a grid - the Y-values are the same as it moves across in the X direction. If you subtract two x-values, you get around 0.002, so I suspect that the original grid file is in 1 arc second increments for the X and Y, but in actual meters for Z. (1 arc second is around 30.87 meters) If you are using QGIS, you can re-import the data and change the projection/conversion to get a correct output file in meters.

1 Like

Thanks for the excellent explanation. Not only did you describe the problem but also explained the concept. Very helpful.

I reprojected the DEM to UTM 44N (that’s what I found is the UTM for Uttar Pradesh, India). However, the data remained the same. I am not sure what went wrong but I cheated and used Scale 2d to scale my point cloud. Worked well and the resulting surface has the correct heights and is not spikey anymore.

I understand this is not accurate because the scaling is referencing one point and since arc second is a spherical projection, it’s going to be off. Any tutorials on correctly projecting from arc second to meters in QGIS?

Thanks again.