On Tue, Dec 22, 2015 at 3:20 PM, Markus Neteler <[email protected]> wrote: > 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.
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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
