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.