[GRASS-dev] [GRASS-SVN] r67222 - grass/trunk/raster/r.in.lidar

[Markus Neteler]

On Sun, Dec 20, 2015 at 3:56 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
...
> This gets little messy and I'm not sure what to do about it.
>
> r.in.lidar imports in region extent only

Why is that so?
The paradigm of r.in.* is to import everything unless dedicated
flags/parameters are activated by the user.

> and with -e it imports according to the data.

I would consider to invert this behaviour to
- by default import all
- restrict to current region using some flag.

Note that r.in.gdal imports all and the -e flag is just changing the WIND file.

> (which can be considered correct as import with
> binning is an analysis thus it should respect the region and resolution must be taken from
> somewhere anyway)

... so that's like r.in.xyz at this point?

> v.in.lidar imports according to data and ignores region extent, while with
> -r it respects the region extent,

.. .complicated :-)

> v.in.lidar sets the region extent according to the input data with -e.
>
> v.in.lidar sets the region extent according to the input data and/or
> resolution option with -n since r67222.
>
> r.in.lidar ignores mask. (which is correct, mask is for reading by default)
>
> v.in.lidar supports mask as a vector map and can invert it with -i.
>
> In the commit message I meant that -e means something else in r.in.lidar and
> v.in.lidar. Since r67222 -n in r.in.lidar is doing what -e is doing in
> v.in.lidar.

Maybe we need a kind of matrix (table) to sync the behaviour across commands.

>> BTW I also don't understand this flag in *r*.in.lidar:
>>   -b   Do not build topology
>
>
> I added vector_output, so then -b makes sense.

I see.

> But perhaps the question is
> if vector_output makes sense for r module.

Maybe not, at least it is not simplifying things.

Markus