id summary reporter owner description type status priority milestone component version resolution keywords cc cpu platform 1142 r.in.poly fails in LL hamish grass-dev@… "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 " defect closed normal 6.4.1 Raster svn-releasebranch64 fixed r.in.poly Unspecified Unspecified