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

[Markus Metz]

On Tue, Dec 22, 2015 at 3:20 PM, Markus Neteler <neteler at osgeo.org> wrote:
> 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.

The other r.in.* modules import raster data. r.in.xyz and r.in.lidar
import point clouds which do not have an inherent resolution.
>
>> 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.

The current behaviour of r.in.lidar is coming from r.in.xyz. When you
pipe input to r.in.xyz, there is no chance to first figure out the
extents, then set the region (which resolution to use?), then do the
import. Ideally r.in.lidar and r.in.xyz continue to behave identical
since both rasterize point clouds.

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

r.in.lidar is a clone of r.in.xyz. BTW, v.in.lidar is a clone of
v.in.ogr. r.in.lidar and v.in.lidar do not have much in common, apart
from using the same input, but the two modules produce very different
output.

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

Not so complicated, as long as you don't expect the two modules to
behave similar. See difference between r.in.xyz and v.in.ogr, or
r.in.gdal and v.in.ascii.

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

Then you should start with r.in.gdal and v.in.ogr, after that try to
apply synchronization to other import modules.

It seems that the confusion arises from expecting fairly similar
behaviour for r.in.lidar and v.in.lidar, which is not really justified
unless you also expect similar behaviour of other raster and vector
import modules.

Markus M

>
>>> 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
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev