[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