[GRASS-user] lidar data - nnbathy x bspline

GRASS GRASS user
1

I did some Lidar interpolation with nnbathy and bspline. data has
~16.5mill points, and final dem has ~35mill cells.
while nnbathy did some very nice results (see image), it took ~8hours
to interpolate. bspline is beautifully fast, did the job in ~1hour,
but the final dem has many artifacts.

I was wondering how to avoid these artifacts with bspline? or with we
could have a vector version of nnbathy?

Carlos

http://www.igc.usp.br/pessoais/guano/temp/lidar_bspline.jpg

http://www.igc.usp.br/pessoais/guano/temp/lidar_nnbathy.jpg

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

2

Hi Carlos and all,

I did some Lidar interpolation with nnbathy and bspline. data has
~16.5mill points, and final dem has ~35mill cells.
while nnbathy did some very nice results (see image), it took ~8hours
to interpolate. bspline is beautifully fast, did the job in ~1hour,
but the final dem has many artifacts.

I was wondering how to avoid these artifacts with bspline? or with we
could have a vector version of nnbathy?

Carlos

http://www.igc.usp.br/pessoais/guano/temp/lidar_bspline.jpg

http://www.igc.usp.br/pessoais/guano/temp/lidar_nnbathy.jpg

The ugly things in the outer regions are due to the interpolation method. I can do nothing. The other artifacts correspond to a badly overlapping between regions. I have more "homeworks" than I expected :-S

I beg your pardon for all these problems and errors. Although the old bspline versions worked nicely, the grass6.x version is quite young (it is available since the end of July) because I rewrote almost everything except the interpolation functions. In the other hand, it was not really tested till now, just when you all began to use it. I know, those are not valid excuses, sorry.

Regards,
Roberto.

3

Hi Carlos and all,

Carlos "Guâno" Grohmann ha scritto:

I was wondering how to avoid these artifacts with bspline? or with we
could have a vector version of nnbathy?

Carlos

http://www.igc.usp.br/pessoais/guano/temp/lidar_bspline.jpg

http://www.igc.usp.br/pessoais/guano/temp/lidar_nnbathy.jpg

I was working on it and I've just update cvs. Now interpolation with v.surf.bspline should works quite nice.

Regards,
Roberto.

--
Roberto Antolín Sánchez
Politecnico di Milano – Polo Regionale di Como
(Laboratorio di Geomatica V2.8)
Via Valleggio, 11 – 22100 Como, Italy
tel: +39 031 332 7533 || fax: +39 031 332 7519 email: roberto.antolin@polimi.it

4

Ciao Roberto.

Nice work with v.surf.bspline! I ran some tests, this time no
artifacts were produced in the sub-regions limits. Alsdo it is very
fast!

I'd just like to poin some issues:

- You could add, in the output messages, a indication of how many
sub-regions will be used, so the user knows approximately how much of
the interpolation has been done, how much still left.

- I tried to use the --overwrite option, but it didn't work.

- I did a test on an area 3.2x0.9 km, with 1m resolution, and it
worked fine. When I changed the resolution to 0.25m, I got an error
msg:

GRASS_INFO_ERROR(12405,3): Interpolation: The region resolution is

too high: 46080000.000000 cells. Consider to change it.

It worked with a resolution of 0.33m, but the resultant surface were
with a "pixelated" look, I don't know if is a problem with bspline or
GRASS dealing with non-round values for UTM regions.

That's all for now. If I find anything more, I'll let you know

Carlos

On 1/15/07, Roberto Antolin <roberto@geomatica.como.polimi.it> wrote:

Hi Carlos and all,

Carlos "Guâno" Grohmann ha scritto:

> I was wondering how to avoid these artifacts with bspline? or with we
> could have a vector version of nnbathy?
>
> Carlos
>
> http://www.igc.usp.br/pessoais/guano/temp/lidar_bspline.jpg
>
> http://www.igc.usp.br/pessoais/guano/temp/lidar_nnbathy.jpg
>
I was working on it and I've just update cvs. Now interpolation with
v.surf.bspline should works quite nice.

Regards,
Roberto.

--
Roberto Antolín Sánchez
Politecnico di Milano – Polo Regionale di Como
(Laboratorio di Geomatica V2.8)
Via Valleggio, 11 – 22100 Como, Italy
tel: +39 031 332 7533 || fax: +39 031 332 7519
email: roberto.antolin@polimi.it

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

5

Hi Carlos and all,

Ciao Roberto.

Nice work with v.surf.bspline! I ran some tests, this time no
artifacts were produced in the sub-regions limits. Alsdo it is very
fast!

I'd just like to poin some issues:

- You could add, in the output messages, a indication of how many
sub-regions will be used, so the user knows approximately how much of
the interpolation has been done, how much still left.

Yes, you are right! I've already thought it. I'll see what I can do.
Just a question, what do you think about the output messages? Are they a lot or are they usefull?

- I tried to use the --overwrite option, but it didn't work.

- I did a test on an area 3.2x0.9 km, with 1m resolution, and it
worked fine. When I changed the resolution to 0.25m, I got an error
msg:

GRASS_INFO_ERROR(12405,3): Interpolation: The region resolution is

too high: 46080000.000000 cells. Consider to change it.

Due to allocation memory problems I have to constrain the number of total cell.
I have to try to resolve this. Anyway, do you really need a 3km^2 DTM with such a resolution? :wink:

It worked with a resolution of 0.33m, but the resultant surface were
with a "pixelated" look, I don't know if is a problem with bspline or
GRASS dealing with non-round values for UTM regions.

Could you give us a link as you did with bspline.jpg and nnbathy.jpg, please?

That's all for now. If I find anything more, I'll let you know

That was a lot! Thank you very much for your help!!

> http://www.igc.usp.br/pessoais/guano/temp/lidar_bspline.jpg
>
> http://www.igc.usp.br/pessoais/guano/temp/lidar_nnbathy.jpg

Another last question, are these immages above the commands output maps or are they aspect raster maps?

Regards,
Roberto.

--
Roberto Antolín Sánchez
Politecnico di Milano – Polo Regionale di Como
(Laboratorio di Geomatica V2.8)
Via Valleggio, 11 – 22100 Como, Italy
tel: +39 031 332 7533 || fax: +39 031 332 7519 email: roberto.antolin@polimi.it

6

Roberto

Yes, you are right! I've already thought it. I'll see what I can do.
Just a question, what do you think about the output messages? Are they a
lot or are they usefull?

I guess they could be reduced. Maybe the user is more interested in
knowing how many sub-regions will be used and in which one the process
is than what are the exact boundaries of the sub-regions.

Due to allocation memory problems I have to constrain the number of
total cell.
I have to try to resolve this. Anyway, do you really need a 3km^2 DTM
with such a resolution? :wink:

I am trying to recreate a DEM some Italian researchers made, and they
used a 0.33m resolution. I tried 0.25m just to see what would happen.

Could you give us a link as you did with bspline.jpg and nnbathy.jpg,
please?

Sure. here they are:

Vesuvius Volcano, 2.5m resolution (you can see that there are still
some artifacts)
http://www.igc.usp.br/pessoais/guano/temp/bspline_2007.jpg

Details:
1m resolution
http://www.igc.usp.br/pessoais/guano/temp/bspline_1m.jpg

0.33m resolution
http://www.igc.usp.br/pessoais/guano/temp/bspline_033m.jpg

Another last question, are these immages above the commands output maps
or are they aspect raster maps?

They are shaded relief maps.

Regards

Carlos

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

7

Hi Carlos and all,

I am trying to recreate a DEM some Italian researchers made, and they
used a 0.33m resolution. I tried 0.25m just to see what would happen.

Vesuvius Volcano, 2.5m resolution (you can see that there are still
some artifacts)

Is this dataset available? I would like to do some test too. Although, those are intrinsic features to the interpolation method (dividing the whole zone into smaller regions) and shaded relief maps (as aspect maps), I'm afraid, I was wondering whether they could be reduced.

If this is not possible, I'll try to give you a better explanation about why they are produced.

Regards,
Roberto.

--
Roberto Antolín Sánchez
Politecnico di Milano – Polo Regionale di Como
(Laboratorio di Geomatica V2.8)
Via Valleggio, 11 – 22100 Como, Italy
tel: +39 031 332 7533 || fax: +39 031 332 7519 email: roberto.antolin@polimi.it

8

Carlos wrote:

> - I did a test on an area 3.2x0.9 km, with 1m resolution, and it
> worked fine. When I changed the resolution to 0.25m, I got an error
> msg:
>
>> GRASS_INFO_ERROR(12405,3): Interpolation: The region resolution is
>> too high: 46080000.000000 cells. Consider to change it.

the current limit is 30000000 /* about 5500x5500 cells */
in vector/lidar/v.surf.bspline/main.c

Roberto Antolin wrote:

Due to allocation memory problems I have to constrain the number of
total cell.
I have to try to resolve this. Anyway, do you really need a 3km^2 DTM
with such a resolution? :wink:

You should let the GRASS libgis memory allocation functions worry about
that, not impose arbitrary limits in a module. Some people have access
to huge computers with lots of resources; or put another way, what is a
massive amount of memory today might be common 3-5 years from now.

At minimum consider changing the G_fatal_error() to a G_warning().

regards,
Hamish