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

GRASS GIS trac at osgeo.org
Sun Jun 5 05:02:29 EDT 2011


#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:  Raster       |     Version:  svn-trunk  
 Keywords:  r.in.xyz     |    Platform:  Unspecified
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by mmetz):

 Replying to [comment:8 hamish]:
 > I'll have a look at r.in.xyz to see if we can change the < to <= ''if we
 are on the last pass block'' without harming module speed much.
 >
 > If we do it for all passes there will be duplicated cells for points
 which fall exactly on pass block borders.
 >

 From a mathematical perspective (is this user hat or dev hat?), the
 current behaviour is correct.

 The user has to decide on a resolution anyway when setting the import
 region, and in order to get nice clean values, alignment to the resolution
 is recommended, i.e. have exactly 1 instead of e.g. 0.98990209. In scan
 mode, the module could print a recommended resolution guestimated from the
 extends and number of points (works only for evenly spaced points), which
 can optionally be rounded to integer values.

 Since the region settings including resolution and alignment, optionally
 to the geometry of an existing raster map, are such a core concept of
 GRASS raster processing, it may not be asked too much to manually set the
 region including resolution first before importing, and I am inclined to
 close the ticket as invalid.

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/123#comment:10>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list