[GRASS-dev] Re: [GRASS GIS] #123: r.in.xyz: import bug when using scanned extent

GRASS GIS trac at osgeo.org
Sat Apr 12 01:50:33 EDT 2008


#123: r.in.xyz: import bug when using scanned extent
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  hamish   
      Type:  defect   |      Status:  assigned 
  Priority:  major    |   Milestone:  6.4.0    
 Component:  default  |     Version:  svn-trunk
Resolution:           |    Keywords:           
----------------------+-----------------------------------------------------
Comment (by hamish):

 On grass-dev, Glynn answered:
 > >  -> one line get's lost.
 >
 > Which one? If it's the first line (the southernmost point), that's
 > probably due to this (raster/r.in.xyz/main.c:588):
 >
 >           if (y <= pass_south || y > pass_north) {
 >
 > The problem with simply changing the test to < is that, for multiple
 > passes, any points on the boundary would be counted twice. The test
 > should be < for the last pass and <= for other passes.
 >
 > Even for floating-point, copying a value and testing a value for
 > equality with itself should work as expected. Rounding errors don't
 > appear out of nowhere, and neither of those operations should
 > introduce rounding errors.
 >
 > If GRASS is introducing rounding errors, the first step should be to
 > try to eliminate them (e.g. ensuring that decimal representations have
 > sufficient digits), rather than working around such errors by adding
 > tolerances.


 Yes, see this comment in r.in.xyz/main.c ("GE" refers to GRASS_EPSILON)

 {{{
 /* The range should be [0,cols-1]. We use (int) to round down,
      but if the point exactly on eastern edge arr_col will be /just/
      on the max edge .0000000 and end up on the next row.
      We could make above bounds check "if(x>=region.east) continue;"
      But instead we go to all sorts of trouble so that not one single
      data point is lost. GE is too small to catch them all.
      We don't try to make y happy as percent segmenting will make some
      points happen twice that way; so instead we use the y<= test above.
      */
 }}}


 and in description.html:

 {{{
 <h4>Filtering</h4>

 Points falling outside the current region will be skipped. This includes
 points falling <em>exactly</em> on the southern region bound.
 (to capture those adjust the region with "<tt>g.region s=s-0.000001</tt>";
 see <em>g.region</em>)
 }}}



 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/123#comment:6>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/


More information about the grass-dev mailing list