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? Markus M
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev