<div dir="ltr"><div><div><br><br>On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> On 22/06/17 15:25, Moritz Lennert wrote:<br>>><br>>> On 22/06/17 14:21, Markus Metz wrote:<br>>>><br>>>><br>>>><br>>>> On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert<br>>>> <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>>><br>>>> wrote:<br>>>>><br>>>>><br>>>>> On 21/06/17 22:19, Markus Metz wrote:<br>>>>>><br>>>>>><br>>>>>><br>>>>>> On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert<br>>>>>> <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>><br>>>><br>>>> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>>>> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>>>> wrote:<br>>>>>>><br>>>>>>><br>>>>>>><br>>>>>>> On 21/06/17 14:57, Markus Neteler wrote:<br>>>>>>>><br>>>>>>>><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> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>><br>>>><br>>>> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>>>> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>>>><br>>>>>><br>>>>>><br>>>>>> wrote:<br>>>>>>>>><br>>>>>>>>><br>>>>>>>>><br>>>>>>>>> Do we really need v.db.univar ? Does it provide anything else/better<br>>>>>><br>>>>>><br>>>>>> than<br>>>>>>>>><br>>>>>>>>><br>>>>>>>>> v.univar ?<br>>>>>><br>>>>>><br>>>>>><br>>>>>> The main difference between v.univar and v.db.univar is that v.univar<br>>>>>> works with geometries while v.db.univar works with the attribute table.<br>>>>>> If vector geometries share the same category value, or if some vector<br>>>>>> geometries have more than one category value, the results of v.univar<br>>>>>> and v.db.univar for the same column will be different. If you want<br>>>>>> results with category (or class) as unit, use v.db.univar, if you want<br>>>>>> results with vector geometry as unit, use v.univar.<br>>>>><br>>>>><br>>>>><br>>>>> Right. Didn't think about this. So they are actually complementary.<br>>>>><br>>>> [...]<br>>>>><br>>>>><br>>>>> However, in the case of multiple cat values per feature, it seems that<br>>>><br>>>> v.univar actually reads the attribute once for every geometry/category<br>>>> combination, not only for each feature:<br>>>><br>>>> According to the source code, yes.<br>>>><br>>>> [...]<br>>>>><br>>>>><br>>>>> I don't know if this is the desired feature or if each geometry should<br>>>><br>>>> only be taken into account once, whatever its number of categories. I<br>>>> personally would have expected the latter, if we consider v.univar to be<br>>>> geometry-based.<br>>>><br>>>> If each geometry should be taken into account only once, a corresponding<br>>>> category / attribute value would need to be randomly picked. Therefore I<br>>>> would prefer to consider all categories for each geometry.<br>>><br>>><br>>> Right.<br>>><br>>>>><br>>>>> All this definitely needs clearer documentation in the man page.<br>>>><br>>>> Attached an attempt to amend the two respective man pages. MarkusM, is<br>>>> this correct ? However, the above question concerning v.univar probably<br>>>> should be checked before I commit this.<br>>>><br>>>> According to the source code, v.univar reads attributes for all<br>>>> categories of a geometry.<br>>><br>>><br>>> Ok.<br>>><br>>>><br>>>> v.db.univar uses db.univar, not db.select, that's an error in the<br>>>> existing manual.<br>>><br>>><br>>> But db.univar uses db.select to access the data, so I don't consider<br>>> this an error in the manual...<br>>><br>>>><br>>>> I suggest to update the manuals first, then decide if the modules should<br>>>> be modified.<br>>><br>>><br>>> Ok. See r71207 and r71208. Please check and tell me if I can backport.<br>><br>><br>> Plus a further attempt at a better formulation for v.db.univar in r71209.<br><br></div>I have modified the description of v.univar regarding distance calculations in r71210,1. Backport now?<br><br></div>Markus M<br></div>