On Thu, Sep 19, 2013 at 9:15 AM, Moritz Lennert <mlenn...@club.worldonline.be> wrote: > On 18/09/13 16:24, Markus Metz wrote: >> >> Moritz Lennert wrote:
>>> Here's a little test: >>> >>> $time v.median in=elev_lid792_randpts >>> 638648.500000|220378.500000 >> >> >> Should be 638648|220378. It seems that numpy gets the median wrong... > > > When I look at the numbers coming out of v.to.db, there are a series of > points at X=638648,5 around the 3000 limit, and a series of points at > Y=220378,5, so I do believe that numpy is right. Right, db.univar was printing out with insufficient precision, fixed in r57750. >> >> About a little module to calculate centroid of polygon, center point >> of line and centroid (possibly weighted) for points, that would be >> easy because all the components are there, even though there are in >> theory alternatives to the current calculation of centroids for >> polygons. > > > And these alternatives are better ? I am not sure. For areas without isles, there is a faster alternative. For areas with isles, the current approach is fast, but the centroids might be placed at somewhat unexpected locations (the next best location inside the area, outside its isles). Here, alternatives would be much slower. Markus M _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev