#1142: r.in.poly fails in LL
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-releasebranch64
Keywords: r.in.poly | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
As reported on the -dev list, r.in.poly is not working in lat/long
locations.
I copied both of your files above into a txt file and used it with
r.in.poly and it worked. r.digit worked as well.
I went back to the original email and copied the file again and it worked
fine. And I made sure the region is set right.
I bet that they had something wrong with how the region was set up
although the region coordinates that they sent were Ok.
So I think you can close it,
Helena
P.S. Among several files with different formatting that work, I still have
this one that is giving NULLs
(perhaps some typo that I don't see)
Everything seems to work just fine on AMD64 with current 6.4. svn, if
region is set correctly. IMHO this is the real bug, as r.in.* should not
be affected by current region.
As goes for Helena's second example - minutes exceed 60 (35:82:00.0N) and
thus whole line gets ignored.
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)
r.in.poly only works with cell maps and transforms any floats to integer.
Perhaps this is part of the problem? We've run into odd results in non LL
regions that ultimately were a result of this.
additional warnings would be nice, but fwiw the man page already says:
{{{
NOTES
The data will be imported using the current region settings
to set the new raster map's bounds and resolution. Any fea-
tures falling outside the current region will be cropped. The
region settings are contolled with the g.region module.
}}}
and
{{{
[...] To give meaning to the features, the "="
indicates that the feature currently being processed has cat-
egory value cat# (which must be an integer) and a label
(which may be more than one word, or which may be omitted).
}}}
bad coord warnings improved in 6.5svn, trunk in r43330, r43331.