r.in.poly fails in LL

[hamish]

As reported on the -dev list, r.in.poly is not working in lat/long locations.

​http://lists.osgeo.org/pipermail/grass-dev/2010-August/051769.html ​http://lists.osgeo.org/pipermail/grass-dev/2010-August/051773.html

apparently it works in 6.3.0 but fails in 6.4.0svn. (I can reproduce it too)

Remember to run g.region first(?),

g.region s=34 n=37 w=-79 e=-77 res=0:01 -p
r.in.poly in=- out=test << EOF
A
 -78.254 35.82
 -78.005 36.201
 -77.707 36.135
 -77.84 35.853
 -78.196 35.721
 -78.254 35.82
= 1 coord
EOF

r.univar test

I have tested r.digit in 6.4.0svn, which is just a front-end to r.in.poly, and it works. The .tmp file it creates looks like this:

AREA
 78:10:08.695652W 36:36:33.569132N
 78:39:25.217391W 35:39:15.62701N
 78:08:24.347826W 34:56:25.85209N
 77:26:57.391304W 35:43:53.440514N
 77:37:23.478261W 36:31:38.392283N
 78:00:17.391304W 35:34:37.813505N
 78:14:12.173913W 35:50:15.434084N
 77:58:50.434783W 36:32:13.118971N
 78:08:59.130435W 36:38:00.385852N
= 3 label

I suspect if you try r.in.poly with D:M:Sh coord notation in it will work.

I have just build 6.4.0rc2, and there it still works there. Will try newer RCs later to try and narrow down the time of this change.

Also, r.in.poly should really be creating geodesic lines between vertices when in a lat/long location. need to check that too.

thanks, Hamish

[helena]

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)

AREA
 78:25:00.0W 35:82:00.0N
 78:00:00.0W 36:20:00.0N
 77:70:00.0W 36:13:00.0N
 77:84:00.0W 35:85:00.0N
 78:25:00.0W 35:82:00.0N
= 1 coord

[marisn]

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.

[hamish]

Replying to 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

[cmbarton]

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.

Michael

[hamish]

tested again in 6.4.0svn, seems ok.

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.

Hamish

[neteler]

Hamish, do you plan to backport r43331? Otherwise it may be closed.

[hamish]

backported to relbr64 by markusN in r43572.