1

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

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 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.

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

Update3:

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).
Community
  • 1
Hakim
  • 956
  • 12
  • 33
  • 1
    Maybe related: http://gis.stackexchange.com/questions/5701/what-is-the-difference-between-dem-dsm-and-dtm – AndreJ Jul 16 '16 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 '16 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 '16 at 16:57
  • Following Aarons comment, I assume that the .asc file was created different from your way with ENVI; maybe using a different set of points, or an earlier survey. – AndreJ Jul 19 '16 at 06:21
  • @AndreJ Actually I downloaded the 2014 surveys for both the *.asc and *.laz files which have a resolution of 1m. But you might be right in that the processing of the *.asc is different from mine with ENVI LiDAR. – Hakim Jul 19 '16 at 09:47
  • @AndreSilva I've followed the steps described here Normalizing a Point cloud, but it's complaing about the output file that's not existant. I've updated my question (see update2), could you see if there is something wrong with the commands I typed? – Hakim Jul 19 '16 at 15:32
  • It should have worked. Never tested "ClipData" without the MinX, MinY, MaxX and MaxY arguments before, but according to Fusion's manual it should work without them (the brackets [] suggest they are optional). But just to be sure, make a test using these arguments. Did you open the .dtm file in Fusion Viewer to inspect if the surface really exists, if coordinates are ok, if there are no holes, etc.? Also, have you checked if your LiDAR point cloud is in projected coordinates (usually, las files are given in projected coordinates)? And also, verify if the .dtm and the .las have same CRS? – Andre Silva Jul 19 '16 at 16:18
  • @AndreSilva I believe both .las and .asc files are projected in the British National Grid (EPSG:27700). Regarding the visualization of the .dtm file, I opened it with <fusion-dir>/pdf.exe but it doesn't really look like the original DTM from which it was produced, which makes me think that the parameters given to ASCII2DTM.exe were wrong. Also, among the parameters of ASCII2DTM.exe (coordsys, zone, horizdatum, vertdatum) some seem to be specific to North America and I'm not sure that this command would work with any DTM, does it? – Hakim Jul 20 '16 at 11:22
  • Yes, it would. I have run this command with DTMs/projections from the south hemisphere (such as SAD69, SIRGAS2000) and it works ok. Do the following: where you wrote: "m m 1 10 2 2", write: "m m 1 10 0 0". It means the horizontal and vertical datum will be unknown for the software. It should work. – Andre Silva Jul 20 '16 at 13:24
  • @AndreSilva even by modifying the parameters of ASCII2DTM to m m 1 10 0 0, I still get the same DTM shape in fusion viewer (pdq.exe) and the subsequent operation (ClipData.exe), as previously, complained about the nonexistence of the output file (which is normal). Here is briefly the error message it returned: Can't open sample file <my-folder>\normalized-lidar.las. – Hakim Jul 20 '16 at 21:43
  • I ran out suggestions considering this workflow; the problem could be that the dtm and the point cloud are not overlapping, so there is no ground to be subtracted in the point cloud (the return elevation [minus] the corresponding dtm pixel elevation). To eliminate this option open the .dtm and .las with one LiDAR data viewer (http://gis.stackexchange.com/questions/1184/ways-to-visualize-multiple-large-lidar-tiles) and check if they overllap. Also, did you try using the Min and Max arguments for x and y in ASCII2DTM as I commented before? – Andre Silva Jul 20 '16 at 22:22
  • 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 '16 at 14:15
  • 1
    Another thing I observed with SNAP (Sentinel Application Platform) software, when I opened the GeoTiff files produced from the dtm.asc and the point-cloud.laz files using QGIS and ENVI LiDAR respectively (as explained in my orginal question), if I put a Ground Control Point in one image it doesn't really match the same location in the other. I wonder what's causing this difference in the geolocation? – Hakim Jul 21 '16 at 14:19
  • @AndreSilva The heights were simply calculated from the pixel intensities of the white building on both produced GeoTIFF images (I've updated the original question). – Hakim Jul 22 '16 at 11:53
  • Ok, that is right. I think you could update the "Update 2" too. – Andre Silva Jul 22 '16 at 12:29
  • 1
    From the latlong coordinates you gave above, EPSG:27700 OSGB36 coordinates should be X=388922 Y=233453. Your extent rather seems to be UTM 30N. – AndreJ Jul 25 '16 at 17:31
  • @AndreJ Is there a difference in the projection between the two files (.asc and .las)? I tried opening the .asc file with Arcmap earlier and it complained about the absence of a spatial coordinate system (no projection). – Hakim Jul 25 '16 at 22:43
  • 1
    I have only looked into the DSM and DTM .asc files. They have no CRS information, but the coordinates in the header are in the range of EPSG:27700, and assigning that CRS the files fit to an OSM background. – AndreJ Jul 26 '16 at 05:44
  • @AndreJ The .las file when opened with ENVI LiDAR shows that the input datum is WGS84 and that the zone is indeed 30N (whereas the .asc file is in the British National Grid). Is it necessary to change the Coordinate Reference System of one of the two files in order for to be comparable? – Hakim Jul 26 '16 at 17:33
  • 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 '16 at 17:59
  • @AndreJ I think I was wrong. I've found online this document UK Environment Agency LiDAR data which says in page 3 that all their products are projected on the British National Grid and that the elevation is measured relatively to the Ordnance Datum Newlyn (which basically just the MSL in Newlyn, Cornall, South West England). Besides, it's only the DSM produced by ENVI LiDAR which has wrong values of elevation (the original point cloud values are consistent with the ASCII one). – Hakim Aug 02 '16 at 16:49

1 Answers1

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).

Hakim
  • 956
  • 12
  • 33
  • What did you mean with "couldn't reproduce the inconsistency". What was the problem, then? – Andre Silva Aug 05 '16 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 05 '16 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. – Andre Silva Aug 05 '16 at 21:18