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. *.asc DEM

*.laz 2014 point cloud, 100cm resolution (file: LIDAR-LAZ-2014-SO83/SO8832_P_9938_20141212_20141212.laz)

White building elevation: around 75m. *.laz DEM


  • 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 with ENVI LiDAR and to produce a DSM in the GeoTIFF format (menu Process > Process Data..., tick only the dsm checkbox) from the given *.laz point cloud (The Export Coordinate System was changed to Geographic Lat/Lon).
  • To follow the terminology in DSM vs DTM, both *.asc and *.laz correspond to a DSM and not a DTM as in both cases the buildings were not flatten. a DTM 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.


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 second Fusion 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


This update concerns a difference in the georeferencing between both .asc and .laz files.

  • If I convert both .asc and .laz files to the GeoTIFF format as explained above, and I open them with the Sentinel Application Platform (SNAP) to put a Ground 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 command clipData by taking these coordinates from the provided .las file (in ENVI LiDAR) I get the following error: No input tiles overlap the sample area: (556547.00,5759837.00) - (558568.00,5761855.00).
  • 1
    Maybe related: gis.stackexchange.com/questions/5701/…
    – AndreJ
    Jul 16, 2016 at 14:50
  • 1
    I suspect that the .asc dataset has been normalized whereas the .laz dataset has not. That is to say, the asc dataset shows elevation above ground level and the laz dataset shows elevation above sea level.
    – Aaron
    Jul 18, 2016 at 12:00
  • 1
    @AndreSilva I tried decompressing the .laz point cloud using LASzip (to get the .las file) as you requested, and producing the DSM using ENVI 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, 2016 at 16:57
  • 1
    @AndreSilva You might be right about the "no-overlap" problem. I did add the minX, minY, maxX, maxY argument to the clipData (not to the ASCII2DTM, guess it was just a typo...), by taking these coordinates values with ENVI LiDAR from the .laz file. Guess what, the clipData 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, 2016 at 14:15
  • 2
    This will surely be necessary. Not just changing the CRS, but reprojecting one dataset to the other CRS. Otherwise the coordinates would not align, and the software complains about no overlap.
    – AndreJ
    Jul 26, 2016 at 17:59

1 Answer 1


I couldn't even reproduce the inconsistency in the heights between the .laz and the .asc files, as the .laz file opened in ENVI LiDAR is now showing elevation values consistent with what shown in QGIS with the .asc file (~25m for the white building above).

As explained in this document UK Environment Agency LiDAR Data, both of these products are projected on the British National Grid and the elevation is measured relatively to the Ordnance Datum Newlyn (which is basically just the Mean-Sea-Level in Newlyn, Cornall, South West England).

  • What did you mean with "couldn't reproduce the inconsistency". What was the problem, then? Aug 5, 2016 at 13:49
  • 1
    @AndreSilva I've just managed to reproduce the inconsistency in the height in ENVI LiDAR, I'll edit my answer later accordingly if necessary. So, when I open the .laz point cloud with ENVI LiDAR and set the projection to EPSG=27700 the height is different from when I set directly the projection to the British National Grid. Obviously, before I was using the former projection, hence the inconsistency in the height shown in ENVI LiDAR. But, I still don't know why the difference in the height values! Knowing that both units are in meters unless the British National Grid<>EPSG:27700.
    – Hakim
    Aug 5, 2016 at 14:29
  • I got it now. I think you should edit your answer to clarify this. About the last sentence on your comment, check it and let us know also through an update in the answer. This way, future readers could benefit from this post if someone faces the same problem you had. Tks. Aug 5, 2016 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.