<div dir="ltr"><div><div><br><br>On Thu, Dec 1, 2016 at 12:01 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> On 30/11/16 09:40, Paulo van Breugel wrote:<br>>><br>>><br>>>> On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert<br>><br>><br>>>><br>>>> > An area() function in r.mapcalc would be nice...<br>[...]<br>><br>>> |r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *<br>>> $PI/180) * float($a)^2";|<br>>><br>><br>> I tested this approach as well. I.e.<br>><br>> area = above formula<br>> pop_density = pop / area<br>><br>> reproject pop_density<br>><br>> pop = pop_density * (ewres*nsres)<br>><br>> It is faster than the <a href="http://r.in.xyz">r.in.xyz</a> approach. But it does not seem to be as precise.<br>><br>> I still lost about 100.000 inhabitants, and more when I smooth more (the "loss" increases from nearest neighbor to bilinear to bicubic).<br>><br>> In order to avoid precision issues, I tried with both density by m2 and density by km2, but results are similar.<br>><br>> I don't know which part of the error comes from the use of spheroid approximation and which part comes from the resampling at reprojection.<br>><br>> But I do think that if it is important to maintain exact totals, then the r.to.vect - v.proj - v.out.ascii - <a href="http://r.in.xyz">r.in.xyz</a> solution seems to be more reliable.<br><br></div>But with this approach you get spatial artefacts. Assume there are 9 cell in source with<br><br>10 10 10 <br>10 10 10 <br>10 10 10<br><br></div>they can become in target e.g.<br><br>10  0 20<br>10  0 20<br>10 10 10<br><div><div><br></div><div>Total count is maintained, but some target cells might receive no source cell whereas other target cells might receive more than one source cell.<br></div><div><br></div><div>Markus M <br></div></div></div>