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