[GRASS-dev] Re: [GRASS GIS] #1142: r.in.poly fails in LL

GRASS GIS trac at osgeo.org
Sat Aug 28 00:43:52 EDT 2010


#1142: r.in.poly fails in LL
-------------------------+--------------------------------------------------
 Reporter:  hamish       |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.0                    
Component:  Raster       |     Version:  svn-releasebranch64      
 Keywords:  r.in.poly    |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by hamish):

 Replying to [comment:2 marisn]:
 > Everything seems to work just fine on AMD64 with current 6.4. svn, if
 region is set correctly.

 I'm going to go back and retest this, I'm sure when I first tested it I
 had run g.region first..

 > IMHO this is the real bug, as r.in.* should not be affected by current
 region.

 That r.in.poly, r.in.xyz, and v.to.rast do not set region for you is not a
 bug. These modules ''create'' raster maps not ''import'' existing arrays.
 There is no good way to decide on what the resolution should be, and
 how/if to align the grid to the bounding box. These are decisions the user
 must make for themselves and are a critical, and very useful, fundamental
 feature of the workflow.


 > As goes for Helena's second example - minutes exceed 60 (35:82:00.0N)
 and thus
 > whole line gets ignored.

 That should give a warning, as should "No features found in current
 region" (ala d.vect). I think to make that "nothing found" warning a
 G_message() though, so you can shut it up with --quiet. (fixed region may
 be what you want)


 cheers,
 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1142#comment:3>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list