Stripe patterns in raster

[Matteo Mura]

Dear all,

I rasterized with blast2dem my CHM derived from lasheight but in the output images (here attached) the LiDAR pulses stripes are visible, giving a unsmoothed surface. The pipeline I used is:

blast2dem -lof file_list.txt -merged -elevation -odir "D:\LiDAR_Molise\Mainarde-matese\NewProcessingMatteo\Height\Unbuffered" -o "CHM.asc"

What is the cause of this result? Is it possible to get a smoother and more precise surface, e.g. modifing some parameter or otrhers?

Thanks a lot for your attention

At soon

Mt M

[Martin Isenburg]

Hello Matteo,

the only way I could help you would be to have access to the height-normalized LAZ files that you are using as input. If you can upload a smaller representative sample that has this problem clearly visible then I could have my laser forestry specialist have a look at it ... (-:

Cheers,

Martin @rapidlasso

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

[Stoker, Jason]

What point density per m2 is your lidar dataset? Top of my head, this could be caused by the data not being dense enough to support the cell size you are rasterizing to.

Jason M. Stoker

Physical Scientist

USGS Earth Resources Observation and Science (EROS)

47914 252nd St.

Sioux Falls, SD 57198

Office: 605-594-2579

Cell: 605-496-3513

My USGS Profile: https://profile.usgs.gov/jstoker

[Matteo Mura]

Hi Jason,

sorry for the delay in answer. The average point density is about 3.5 points/m^2, but there are area in the bare ground and flat terrain where the density is less than 1 point/m^2 (only the first return has been recorded), while in the vegetated covers the point density reach up to 9 points/m^2 (many first and last returns recorded for sqm). I would agree with your hypotesis if I used lasgrid because it does not interpolates but just grid according to the pixel size, but I used blast2dem, which use an algorithm to interpolate values in missing pixels so such strip patterns should not be visibles. Or may be I am wrong and I am missing some aspectsd of the processing, you are surely more expert than me, let me know what you think about.

Thanks for your attention

Best regards

Matteo

[Stoker, Jason]

Hi Matteo

I think there may be a few ways to see if this is the case- first, see if the stripes in the blast2dem result correlate with your nodata pixels in the las2grid image you made.  If yes, then you know that those areas where there are few/no lidar returns are probably causing your stripes by blast2dem interpolating across where there is no data.  I think another way would be to create a density grid in lasgrid, using the same cell (step) size as your output- if your stripes are showing up in areas where you have few/no points, you would know these are probably the cause.  The third way I can think of is to increase your -step size and see if those stripes are still there.  You could try the blast2dem with a -step 1, then another iteration with a -step 1.5, then another with a -step 2, then another with a -step 3.  I think you should see less striping the bigger your step size gets.  You can decide at what step is best, where you have the highest resolution with no striping.

My guess is that while on average your data may support a 1 meter step size, due to the data not having a consistent point density throughout, you may need to increase the step size to have consistent results back for the whole area. And personally, I would rather have consistent, lower resolution results over higher-res noisy results.

Jason M. Stoker

Physical Scientist

USGS Earth Resources Observation and Science (EROS)

47914 252nd St.

Sioux Falls, SD 57198

Office: 605-594-2579

Cell: 605-496-3513

My USGS Profile: https://profile.usgs.gov/jstoker

[James Dunnam]

Looking at your images, I would say that it's not blast2dem, it's poor lidar data calibration. That image is a classic representation of poor roll or scale adjustments made to the flight lines.

[Matteo Mura]

Hi Jason,

Here the results of your suggested ways I had already tried when the problem occurred, but an assessment of it from eyes (and knowledge) more expert than mine I think is better.

1. blast2dem vs lasgrid. It is difficult to assess if they are correlated. The strip patterns are so frequent and somehow sistematic, while the noise seems to show a more homogeneus distribution. But I think they are not correlated because in the flat terrain/ground blank pixels are present in the grid and not in the interpolated surface.

2. Same observations. Blank pixels are located exactely in the same locations for both height ann density grid surfaces.

3. This is OK. Increasing the pixel size the problem does not occur. We are carring out 2 works. In the estimation one [V or Biomass = f(LiDAR metrics)] the pixel size is of 23 m to reproduce the plot size as better as possible (13 m radius). But We need also a 1-m resolution pixel to test a LiDAR-based segmentation (and here are the problems).

Here attached the example images.

Thanks a lot for your priceless time Jason

At soon

Mt M

2013/7/16 Stoker, Jason <jst...@usgs.gov>

[Matteo Mura]

Ah! OK. 

The truth is that we have not the original .las files, they gave us just the .txt files of the tiles and I converted them to .las by txt2las in order to be able to process the data with lastools.

So, Jason, I do not want to subtract to you your time but now you are somehow involved and aware of the question, do you have any suggestion to correct such problem or we have to accept it without solutions?

Matteo

2013/7/17 James Dunnam <james...@gmail.com>

[Martin Isenburg]

Hello all,

in the meantime Matteo has sent me one normalized LAZ tile so I took a closer look. The spacing of the LiDAR returns in his data is too low (or too uneven) to simply lasgrid the highest elevation return onto 1 meter by 1 meter grid cells. This gives two undesirable artifacts: (1) empty cells and (2) canopy cells with ground or mid-canopy elevation (see first attached image).

lasgrid -i tile_434000_4596000.laz ^

             -highest -false -set_min_max 0 25 ^

             -ll 434000 4597750 -ncols 1000 -nrows 250 ^

             -odix _1m -opng

One way to "anti-alias" the sparse LiDAR samples is the option '-subsample 3' which will - quoting the README file - add "each LiDAR point 9 times to the raster at locations (x/y), (x+0.33*step/y), (x+0.66*step/y),(x/y+0.33*step) (x+0.33*step/y+0.33*step) (x+0.66*step/y+0.33*step), (x/y+0.66*step) (x+0.33*step/y+0.66*step) (x+0.66*step/y+0.66*step) and thereby "washes out" hard boundaries. Obviously, this will lead to wrongful increase in the '-density' counters, but the '-averages', '-highest', '-lowest', and '-stddev' will have less aliasing.". This adds a slight directional bias (i may need to fix that) but it does help a bit (see second attached image).

lasgrid -i tile_434000_4596000.laz ^

             -highest -false -set_min_max 0 25 ^

             -subsample 3 ^

             -ll 434000 4597750 -ncols 1000 -nrows 250 ^

             -odix _1m_s3 -opng

One way to fill the few missing pixels would be the '-fill 1' option which fills empty pixels by averaging the neighbors that are within a 1 pixel radius but this does not always average the right value and does not improve the areas where we had mid-canopy or ground elevations in the canopy instead of empty pixels (see third attached image).

lasgrid -i tile_434000_4596000.laz ^

             -highest -false -set_min_max 0 25 ^

             -subsample 3 -fill 1 ^

             -ll 434000 4597750 -ncols 1000 -nrows 250 ^

             -odix _1m_s3_f1 -opng

So I added an option called '-subcircle 0.50' that inserts 8 additional points of equal elevation arranged in a circle of radius 0.50 around each original LiDAR point. This option will become available in the next release. This starts to produce nice looking results for a radius 0.75 but be aware that this also "smears out" the sampled canopy. Attached are the results for radius 0.50 and 0.75 .

lasgrid -i tile_434000_4596000.laz ^

             -highest -false -set_min_max 0 25 ^

             -subcircle 0.50 ^

             -ll 434000 4597750 -ncols 1000 -nrows 250 ^

             -odix _1m_c0.50 -opng

lasgrid -i tile_434000_4596000.laz ^

             -highest -false -set_min_max 0 25 ^

             -subcircle 0.75 ^

             -ll 434000 4597750 -ncols 1000 -nrows 250 ^

             -odix _1m_c0.75 -opng

Cheers,

Martin @rapidlasso

PS: please folks, do not use the '-reversible' option with lastile unless you plan to revert your tiled data back to the original strips

[Stoker, Jason]

Matteo, I like Martin's new option, very slick!  My only caution is that this 'fix' may falsely imply that the source data is better than what it is, so make sure you document anything like this that you do.  A purist might call this airbrushing for lidar data :-)  Martin, I'm looking forward to messing around with this-seems that it could be much better than the standard fill option in certain cases.

No matter what the cause of the gaps in the data- poor calibration, etc- it is what it is, and what it appears to be is source data that can't get you 1 meter resolution rasters without no data issues in some places.  I'd try Martin's new solution, but ideally I think you should simply use a cell size that is larger than 1 m.  What I have always done in the past to be safe is to use a cell size that guarantees all cells have at least 1 actual lidar return in them. 

The whole idea of how we document Nominal Post Spacing consistently has been something we have struggled with for years.  What your point density is depends on so many things.  As you have seen, on average your data does support creating 1 meter resolution rasters, but averages do not mean everywhere.  So technically no one lied to you about the point density.    This can also work the other way- where you may have an project that is collected at 9 pts/m2, but there are a ton of waterbodies in there, and in those areas you get few to no returns.  So if you were to compute average point density for the entire project your average point density may only be 1 pt/m2, even though in the areas you care about it is much higher.

Let us know what you end up doing, and how it turns out. 

Good luck!

Jason

[Matteo Mura]

Hi folk,

I tried the "-subcircle" option at 0.75. It has been compared with the lasgrid standard version. Blank pixels still compare in the 0.75 run (what a data they gave us!!!). Attached the results.

I compared the pixels values and raster statistic of both layers. While the raster statistics (MAX, MIN, MEAN, STDEV) values are comparable without to bias the estimations, at the pixel level the values are too far (discrepancies also of +/- 3 m in the CHM). This can lead to a biased estimations of forest parameters such as volume or biomass.

In the end I decided to use a bigger pixel step (5 m) for the estimation (at least these values comes from actual LiDAR points) and to use the subcircle option to generate a CHM 1 as a base for the segmentation, so it will be used as a "qualitative" layer and not as a "quantitative" one.

Thanks a lot guys for your support and clarifications.

All the best

Matteo