The following question concern the same type of data as the one I've asked in Differences in the longitude and latitude between a LiDAR DSM and an optical image.
Basically, I've downloaded a tile of the DSM
for the UK from UK Survey Open Data. The DSM
is available under two extensions: *.laz
or *.asc
files.
The thing I cannot understand is the difference in the elevation values between these two types of data. Below are the two DSM
files together with the elevation of the rectangular building seen in white. Note that the *.asc
file was opened with QGIS
and saved in GeoTiff
format while the *.laz
files was opened using ENVI LiDAR
and processed to produce the DSM
from it. The elevation of the building in each image was retrieved roughly from its pixel intensities in the produced GeoTIFF
images.
*.asc 2014 DSM, 100cm resolution (file: LIDAR-DSM-1M-2014-SO83/dsm_d0177253_20141212_20141212_mm_units.asc)
White building elevation: around 25m.
*.laz 2014 point cloud, 100cm resolution (file: LIDAR-LAZ-2014-SO83/SO8832_P_9938_20141212_20141212.laz)
White building elevation: around 75m.
Update1:
- The
*.asc
files was downloaded directly from UK Survey Open Data, and used as is with no further processing on my part. - The only processing I carried out on the
*.laz
files was to open it withENVI LiDAR
and to produce aDSM
in theGeoTIFF
format (menuProcess > Process Data...
, tick only thedsm
checkbox) from the given*.laz
point cloud (TheExport Coordinate System
was changed toGeographic Lat/Lon
). - To follow the terminology in DSM vs DTM, both
*.asc
and*.laz
correspond to aDSM
and not aDTM
as in both cases the buildings were not flatten. aDTM
is available on UK Survey Open Data where you can clearly see that the location where the building is supposed to be is almost the same elevation as the ground near it. - The tile in the screenshots is
SO83
. It's in the city of Tewkesbury (Gloucestershire, England). - The (latitude, longitude) of the building are (51.999409, -2.162770), in case one needs to visualize it on
Google Earth
.
Update2:
In order to investigate what had caused the differences in the heights between the two files (.las
and .asc
), I tried normalizing the .las
file (the uncompressed version of the .laz
file) using a software called Fusion
, as described in Normalizing point cloud data:
- Since the
DTM
is available in.asc
format, it needs to be converted first to.dtm
format so that it could be given as an input to the secondFusion
command. Below is the command I typed on the prompt (The*.asc
is the input file, and the*.dtm
is the output file):
ASCII2DTM <my-folder>\lidar.dtm m m 1 10 0 0 <my-folder>\dtm_f0177253_20141212_20141212_mm_units.asc
- The previous command worked well, but not the one that actually normalized the
.las
file (i.e. flatten the ground):
ClipData /height /dtm:<my-folder>\lidar.dtm <my-folder>\SO8832_P_9938_20141212_20141212.las <my-folder>\normalized-lidar.las
Update3:
This update concerns a difference in the georeferencing between both .asc
and .laz
files.
- If I convert both
.asc
and.laz
files to theGeoTIFF
format as explained above, and I open them with theSentinel Application Platform (SNAP)
to put aGround Control Point
in one of them, it doesn't match the same location in the other. Something might be responsible for the differences in the georeferencing! - If I add the
minX, minY, maxX, maxY
arguments to the previous commandclipData
by taking these coordinates from the provided.las
file (inENVI LiDAR
) I get the following error:No input tiles overlap the sample area: (556547.00,5759837.00) - (558568.00,5761855.00).
.laz
point cloud usingLASzip
(to get the.las
file) as you requested, and producing theDSM
usingENVI LiDAR
with the.las
as an input, but I'm still getting the same elevations values as with the.laz
file. I will try normalizing the point cloud and let you know if that's the issue – Hakim Jul 18 '16 at 16:57minX, minY, maxX, maxY
argument to theclipData
(not to theASCII2DTM
, guess it was just a typo...), by taking these coordinates values withENVI LiDAR
from the.laz
file. Guess what, theclipData
command worked without an error, but I got this message on the terminal:No input tiles overlap the sample area: (556547.00,5759837.00) - (558568.00,5761855.00)
. – Hakim Jul 21 '16 at 14:15