ASC file: xllcorner/yllcorner versus xllcenter/yllcenter

[Martin Isenburg]

Hello folks,

there was a question about the *.asc grid format a while ago: which location in each cell does the elevation value correspond to. My understanding is that the values in an *.asc grid will ALWAYS correspond to the center of the grid cell - no matter if the location of the lower left grid cell is specified via the xllcorner/yllcorner coordinate pair or via the xllcenter/yllcenter coordinate pair. A long exchange on this topic (read all the way to the end) is can also be found here [1].

Here a small example using the data set 'house.laz' that is in the LAStools\data folder of each LAStools.zip distribution. First we check was lasinfo tells us about the extend:

D:\LAStools\bin>lasinfo -i ..\data\house.laz

[...]

  min x y z:                  309227.00 6143455.00 451.40

  max x y z:                  309268.99 6143496.99 471.39

[...]

So the x values range from 309,227 to 309,269 (a range of 42 meters) and the y values range from 6,143,455 to 6,143,497 (also a range of 42 meters). Next I create a coarse 10 meter DTM raster from ground points with las2dem (or blast2dem):

D:\LAStools\bin>las2dem -i ..\data\house.laz ^

                                         -keep_class 2 ^

                                         -step 10 ^

                                         -o house.asc

With a step size of 10 meter the temporary TIN that is constructed from the ground points ('-keep_class 2') we end up with an ASC grid covering the x range of 309,220 to 309,270 (50 meters) and the y range 6,143,450 to 6,143,500 (also 50 meters).

D:\LAStools\bin>more house.asc

ncols 5

nrows 5

xllcorner 309220.000000

yllcorner 6143450.000000

cellsize 10.000000

NODATA_value -9999.0

-9999.0 459.98 460.64 460.07 458.95

-9999.0 459.96 459.85 458.94 454.77

-9999.0 459.80 459.40 458.92 454.18

-9999.0 459.14 459.36 457.92 453.94

-9999.0 457.89 456.73 454.37 452.02

As each of the 10 meter by 10 meter cells is sampled in the center we get a column of no data values on the right side of the raster. This is to be expected as the x coordinate of all of these cells is 309,220 + (10/2) = 309,225 and hence outside the coverage of the LiDAR points that starts at 309,227. 

By generating XYZ instead of ASC output we only get those cells that actually contain an elevation value (together with their x/y coordinate), so we should get 20 lines in the output:

D:\LAStools\bin>las2dem -i ..\data\house.laz ^

                                         -keep_class 2 ^

                                         -step 10 ^

                                         -o house.xyz

In order to sample the TIN differently we would need to shift the entire grid. Hence a flag such as '-grid_ll' might be needed to allow shifting the generated grid off the lower left coordinate that is currently always a multiple of the requested '-step' size. This issue (and a temp solution) was also raised in this thread:

http://groups.google.com/d/topic/lastools/a06LU--Tb5A/discussion

 

Regards.

Martin @rapidlasso

[1] http://www.goldensoftware.com/forum/viewtopic.php?t=4017

On Wed, Nov 25, 2015 at 12:42 PM, <Karin...@ldbv.bayern.de> wrote:

Hello everybody,

 

right now we are changing our LiDAR data from ASCII to LAZ format. In my workflow I have to integrate DTM processing and integrating LAZ data from image matching.

 

[...]

 

-       blast2dem works wonderful (besides the "vertex not in hash" problem), but it creates .asc files with a header information

        xllcorner

        yllcorner

       although the height (z-value) is in the center of the cell.

       Some programs can interpret xllcorner and xllcenter in the header, so there is a problem when calculating differences or merging grids.

 

Maybe some other users have the same problem.

 

Thanks

Karin