[GRASS-dev] [GRASS GIS] #3001: r.in.xyz -s scan mode: one row/col lost?

[GRASS GIS]

#3001: r.in.xyz -s scan mode: one row/col lost?
----------------------+-------------------------
  Reporter:  neteler  |      Owner:  grass-dev@…
      Type:  defect   |     Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |    Version:  svn-trunk
Resolution:           |   Keywords:  r.in.xyz
       CPU:  All      |   Platform:  Linux
----------------------+-------------------------

Comment (by wenzeslaus):

 The exported points are in a grid and the points are placed in centers of
 original raster cells. This explains why the region is one cell smaller.
 With the same resolution and alignment to the input data (i.e. to the
 points rather than the original raster). This causes the new raster to
 begin in the middle of the cell from the original raster and end similarly
 in the middle of the original cell. It is therefore one cell smaller (2 *
 0.5 cell) than the original.

 During the actual import, the points on some borders (I was not able to
 figure out which ones) are probably left out due to floating point
 comparisons. When you make the region 1 meter bigger on each side, all
 points are imported and the central row and column have 2 cells in them
 and central cell has 4.

 Here is the relevant `r.in.xyz` code:

 {{{
 #!c
 if (y <= region.south || y > region.north) {
     G_free_tokens(tokens);
     continue;
 }
 if (x < region.west || x >= region.east) {
     G_free_tokens(tokens);
     continue;
 }
 arr_row = (int)((region.north - y) / region.ns_res) - row0;
 if (arr_row < 0 || arr_row >= rows) {
     G_free_tokens(tokens);
     continue;
 }
 arr_col = (int)((x - region.west) / region.ew_res);
 /* no check of arr_col */
 }}}

 `r.in.lidar` behaves the same as `r.in.xyz` and uses the same code to
 exclude the points. Tested with:

 {{{
 r.to.vect in=elevation out=elevation_vector type=point -btz
 v.out.lidar in=elevation_vector out=elevation.las
 }}}

 `v.in.ascii -r` (import in region only) gives all the points, the code is:

 {{{
 if ((window.east < easting) ||
     (window.west > easting))
     skip = TRUE;
 if ((window.north < northing) ||
     (window.south > northing))
     skip = TRUE;
 }}}

 Changing the `<=` and `>=` to `<` and `>` imports 2023500 points (more
 than 2022151 but not 2025000) but that doesn't look like good idea anyway.
 I'm even worried about not checking `arr_col` (I ended up checking row,
 col, depth in `r3.in.lidar` since checking coordinates was not reliable).

 I think the current behavior might miss few points (max 4?) for randomly
 distributed points when region would be aligned to points rather than
 resolution (`g.region -a`). For points in grid as in this case, the user
 is responsible for dealing with floating point issues and gridded data
 specifics with the current implementation.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3001#comment:1>
GRASS GIS <https://grass.osgeo.org>