On Sun, Dec 20, 2015 at 3:56 AM, Vaclav Petras <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
