Le 23 juin 2017 08:38:43 GMT+02:00, Markus Metz <markus.metz.gisw...@gmail.com> a écrit : >On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert < >mlenn...@club.worldonline.be> wrote: >> >> On 22/06/17 15:25, Moritz Lennert wrote: >>> >>> On 22/06/17 14:21, Markus Metz wrote: >>>> >>>> >>>> >>>> On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert >>>> <mlenn...@club.worldonline.be ><mailto:mlenn...@club.worldonline.be>> >>>> wrote: >>>>> >>>>> >>>>> On 21/06/17 22:19, Markus Metz wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert >>>>>> <mlenn...@club.worldonline.be ><mailto:mlenn...@club.worldonline.be> >>>> >>>> <mailto:mlenn...@club.worldonline.be >>>> <mailto:mlenn...@club.worldonline.be>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 21/06/17 14:57, Markus Neteler wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert >>>>>>>> <mlenn...@club.worldonline.be ><mailto:mlenn...@club.worldonline.be> >>>> >>>> <mailto:mlenn...@club.worldonline.be >>>> <mailto:mlenn...@club.worldonline.be>>> >>>>>> >>>>>> >>>>>> 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. >>> >>> >>> Right. >>> >>>>> >>>>> 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. >>> >>> >>> Ok. >>> >>>> >>>> v.db.univar uses db.univar, not db.select, that's an error in the >>>> existing manual. >>> >>> >>> But db.univar uses db.select to access the data, so I don't consider >>> this an error in the manual... >>> >>>> >>>> I suggest to update the manuals first, then decide if the modules >should >>>> be modified. >>> >>> >>> Ok. See r71207 and r71208. Please check and tell me if I can >backport. >> >> >> Plus a further attempt at a better formulation for v.db.univar in >r71209. > >I have modified the description of v.univar regarding distance >calculations >in r71210,1. Backport now?
+1 But traveling so can't do it before next week. Moritz > >Markus M _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev