<div dir="ltr"><br><div>On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> On 21/06/17 14:57, Markus Neteler wrote:<br>>><br>>> On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert<br>>> <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>>>><br>>>> Do we really need v.db.univar ? Does it provide anything else/better than<br>>>> v.univar ?<br><br></div><div>The main difference between v.univar and v.db.univar is that v.univar works with geometries while v.db.univar works with the attribute table. If vector geometries share the same category value, or if some vector geometries have more than one category value, the results of v.univar and v.db.univar for the same column will be different. If you want results with category (or class) as unit, use v.db.univar, if you want results with vector geometry as unit, use v.univar.<br><br></div><div>v.univar can also compute statistics on the distances between vector geometries. There is no explanation in the manual what this should be good for. Markus N, you wanted this feature many years ago, do you remember why?<br></div><div><br></div><div>Markus M<br></div><div><br>>>><br>>>> Just to avoid module bloat and maybe rationalize when possible.<br>>><br>>><br>>> +1 but mayI cite you... :-)<br>>><br>>> <a href="https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html">https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html</a><br>>> (copy below)<br>><br>><br>> It's always good to be reminded of the things one said in the past. ;-)<br>><br>> However, the module has evolved quite a lot since that discussion, and in the direction contrary to what I said in terms of distinguishing the two.<br>><br>> At this stage, I don't see anything in v.db.univar that is not also provided by v.univar, but v.univar provides more options than v.db.univar. And since v.univar is C, I would suggest keeping that module.<br>><br>> Its man page needs some love, however, as I have the feeling that not all info is correct. Notably:<br>><br>> "When using the -d flag, univariate statistics of vector geometry are calculated. Depending on the selected vector type, distances are calculated as follows:<br>><br>>     type=point: point distances are considered;<br>>     type=line: the first point of each line is considered;<br>>     type=area: the centroid of each area is considered."<br>><br>> but type=area actually creates a fatal error. You have to explicitely ask for type=centroid.<br>><br>> It might be interesting, in the long run, to output some general statistics on geometries (e.g. on area and perimeter for areas, on length for lines), but that would mean duplicating some of v.to.db's code...<br>><br>><br>>> Since sime time passed, we may indeed want to revisit the topic.<br>><br>><br>> +1<br>><br>> Moritz<br>><br>><br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br><br></div></div>