Define origin of tif image created by lasgrid

[Ellon Mendes]

    Hi all,

Is there any way to set the origin of a tif image being created using
lasgrid? I noticed the origin is being set to min x, max y of the input
cloud, but I would like to control it to match a orthoimage I have from
the same region.

Regards,

Ellon

[gberard]

Ellon,

Check out these three options from the readme:

-nrows 256             : raster at most 256 rows (starting from the lower left)
-ncols 512             : raster at most 512 columns (starting from the lower left)
-ll 300000 600000      : start rastering at these lower left x and y coordinates

The GeoTIFF origin will be the upper-left as you pointed out, but since you know the pixel size you should be able to get there using the above.

Greg

[Ellon Mendes]

    Hi Greg,

Thanks for your answer. I found these two options a little after sending the email, but I still didn't get the result I want.

My RGB raster has the following size, origin and pixel size as informed by gdalinfo:

Size is 4698, 3650
Origin = (352962.034534013189841,4799636.841214870102704)
Pixel Size = (0.071240000000000,-0.071240000000000)

I computed a min_y for the -ll option as

4799636.841214870102704 - 0.07124 * 3650 = 4799376.815214870102704

Then I use lasgrid with the following options:

lasgrid -i prepared/all_14_Riegl_0000001.laz \
        -step 0.07124 \
        -highest \
        -false \
        -ll 352962.034534013189841 4799376.815214870102704 \
        -ncols 4698 -nrows 3650 \
        -odir rasters \
        -o chm_grd.tif

but I got different origin in chm_grd.tif from gdalinfo (red highlights the difference):

Origin = (352961.999520000012126,4799636.775959999300539)

Visually I got the result you can see in the attached image from QGIS. I'm also attaching the complete gdalinfo output.

It seems to me that if I set the origin with -ll, -ncols, -nrows I should get the same values, specially the origin's x coordinate, that I set to be the same as the RGB gdal image.

Maybe it is related with the center of the pixel (top-left corner versus center)? But In this case I think my chm image would have be shifted by half-pixel, and that's not the case. Could it be a float-point precision problem?

Regards,

Ellon

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[gberard]

Hmm, maybe you're right about it being a rounding error.  Your X does appear to be off by ~1/2 pixel, though, so the origin interpretation could be playing in as well.

If you're comfortable simply shifting one of the datasets slightly you could also try using gdalwarp with "-te" to set the target extents and "-r near" to avoid changing the pixel values.

Good luck!

Greg

[Martin Isenburg]

Hello Ellon,.

to shift the rasters that lasgrid and lascanopy produce on a sub-pixel level there is the command -grid_ll shiftx shifty where shiftx and shifty must be a number between 0 and the step size. Below a small example. 

lasgrid -i ..\data\fusa.laz -step 1.0 -o fusa_1m.asc

more fusa_1m.asc

ncols 250

nrows 250

xllcorner 277750.000000

yllcorner 6122250.000000

cellsize 1.000000

NODATA_value -9999.0

45.20 44.90 42.40 42.40 42.41 42.41 42.39 42.31 [...]

lasgrid -i ..\data\fusa.laz -step 1.0 -grid_ll 0.25 0.25 -o fusa_1m_shifted_25cm.asc

more fusa_1m_shifted_25cm.asc

ncols 251

nrows 251

xllcorner 277749.250000

yllcorner 6122249.250000

cellsize 1.000000

NODATA_value -9999.0

-9999.0 45.26 42.40 42.42 42.41 42.43 42.41  [...]

It seems more tricky with your odd step size. To figure out what shift to use you need to compute the remainder of your intended lower left coordinate pair and the step size.

Here is my calculation for x:

352962.034534013189841 / 0.07124 = 4954548.491493728099957888826502

.491493728099957888826502 * 0.07124 = 0.035014013189841

Here is my calculation for y:

4799376.815214870102704 / 0.07124 = 67369129.915986385495564289724874

.915986385495564289724874 * 0.07124 = 0.065254870102704

So this one here should shift the pixels of the raster generated by lasgrid to align with your other raster.

lasgrid -i prepared/all_14_Riegl_0000001.laz ^
        -step 0.07124 ^
        -highest ^
        -false ^
        -ll_grid 0.035014013189841 0.065254870102704 ^

        -odir rasters ^
        -o chm_grd.tif

Could you try and report success, failure, or what you had to modify further?

Regards,

Martin @rapidlasso

[Ellon Mendes]

    Hi Martin,

Thanks for your answer. I tried your solution, but lasgrid tells me it cannot understand the argument -ll_grid:

lasgrid -i prepared/all_14_Riegl_0000001.laz \
        -step 0.07124 \
        -highest \
        -false \

        -ll_grid 0.035014013189841 0.065254870102704 \
        -odir rasters \
        -o chm_grd_fix.tif
ERROR: cannot understand argument '-ll_grid'

I'm using version 170915:

lasgrid -version
LAStools (by mar...@rapidlasso.com) version 170915 (academic)

This option does not appear to be documented in any README nor matched in any binary file (as informed by grep). Is this option really available on lasgrid?

Best,

Ellon

[Martin Isenburg]

Sorry. Typo!!! Look at my small example that uses 'fusa.laz' that was for you to repeat. It uses '-grid_ll' not '-ll_grid'. My bad.

[Ellon Mendes]

Oops, I didn't notice the typo neither. :)

I confirm that with -grid_ll option and the remainder computation I get a perfect match between of the lasgrid and the RGB image I was given, with a step of 0.07124.

Thanks for the help!

Ellon