On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert < [email protected]> wrote: > > On 21/06/17 22:19, Markus Metz wrote: >> >> >> On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert >> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> On 21/06/17 14:57, Markus Neteler wrote: >>>> >>>> >>>> On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert >>>> <[email protected] <mailto:[email protected]>> >> >> wrote: >>>>> >>>>> >>>>> Do we really need v.db.univar ? Does it provide anything else/better >> >> than >>>>> >>>>> v.univar ? >> >> >> 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. > > > Right. Didn't think about this. So they are actually complementary. > [...] > > However, in the case of multiple cat values per feature, it seems that v.univar actually reads the attribute once for every geometry/category combination, not only for each feature:
According to the source code, yes. [...] > > I don't know if this is the desired feature or if each geometry should only be taken into account once, whatever its number of categories. I personally would have expected the latter, if we consider v.univar to be geometry-based. If each geometry should be taken into account only once, a corresponding category / attribute value would need to be randomly picked. Therefore I would prefer to consider all categories for each geometry. > > All this definitely needs clearer documentation in the man page. Attached an attempt to amend the two respective man pages. MarkusM, is this correct ? However, the above question concerning v.univar probably should be checked before I commit this. According to the source code, v.univar reads attributes for all categories of a geometry. v.db.univar uses db.univar, not db.select, that's an error in the existing manual. I suggest to update the manuals first, then decide if the modules should be modified. Markus M
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
