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>> 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>>
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.
Just to illustrate:
g.copy vect=urbanarea,ua
v.category ua op=report
Layer/table: 1/ua
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 657 1 108
area 0 0 0
face 0 0 0
kernel 0 0 0
all 657 1 108
v.info -t ua
nodes=828
points=0
lines=0
boundaries=1311
centroids=657
areas=666
islands=183
primitives=1968
map3d=0
v.db.addcolumn ua col="testval integer"
v.db.update ua col=testval val=1
v.db.univar ua col=testval
[...]
Sum: 108
v.univar ua col=testval
[...]
sum: 657
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:
v.in.ascii in=- out=testpoints <<EOF
640000|220000
640100|220000
EOF
v.db.addtable testpoints
v.buffer -t testpoints out=testbuffer dist=150
v.category testbuffer op=report
Layer/table: 1/testbuffer
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 4 1 2
area 0 0 0
face 0 0 0
kernel 0 0 0
all 4 1 2
v.info -t testbuffer
nodes=4
points=0
lines=0
boundaries=6
centroids=3
areas=3
islands=1
primitives=9
map3d=0
v.db.addcolumn testbuffer col="testval integer"
v.db.update testbuffer col=testval val=1
v.db.univar testbuffer col=testval
[...]
Sum=2
v.univar testbuffer col=testval
[...]
sum: 4
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.
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.
Moritz
Index: vector/v.univar/v.univar.html
===================================================================
--- vector/v.univar/v.univar.html (révision 71176)
+++ vector/v.univar/v.univar.html (copie de travail)
@@ -1,10 +1,13 @@
<h2>DESCRIPTION</h2>
-<em>v.univar</em> calculates univariate statistics of vector map features.
-This includes the number of features counted, minimum, maximum values,
-and range.
-Variance and standard deviation is calculated only for points if
-<b>type=point</b> is defined.
+<em>v.univar</em> calculates univariate statistics on (by default) an attribute
+of, or, through the <b>-d</b> flag on distance between, vector map features.
+Statistics are read by feature, not by category value. This means that if the
+map contains several features with the same category value, the attribute is
+read as many times as there are features. On the other hand, if a feature has
+more than one category value, the attribute is only read once. For statistics
+on attributes per category value, see
+<a href="v.db.univar.html">v.db.univar</a>.
<p>Extended statistics (<b>-e</b>) adds median, 1st and 3rd quartiles, and 90th
percentile to the output.
@@ -18,7 +21,9 @@
<ul>
<li> <b>type=point</b>: point distances are considered;</li>
<li> <b>type=line</b>: the first point of each line is considered;</li>
-<li> <b>type=area</b>: the centroid of each area is considered.</li>
+<li> <b>type=area</b>: not supported, use type=centroid instead (and see
+ <a href="v.distance.html">v.distance</a> for calculating distances
+ between areas)</li>
</ul>
<h2>EXAMPLE</h2>
@@ -116,6 +121,7 @@
<a href="r.univar.html">r.univar</a>,
<a href="v.db.univar.html">v.db.univar</a>,
<a href="v.neighbors.html">v.neighbors</a>
+<a href="v.distance.html">v.distance</a>
</em>
Index: scripts/v.db.univar/v.db.univar.html
===================================================================
--- scripts/v.db.univar/v.db.univar.html (révision 71205)
+++ scripts/v.db.univar/v.db.univar.html (copie de travail)
@@ -3,9 +3,18 @@
<em>v.db.univar</em> calculates basic univariate statistics for numeric
attributes in a vector attribute table. It will calculate minimum,
maximum, range, mean, standard deviation, variance, coefficient of
-variation, quartiles, median, and 90th percentile.
-It uses <em>db.select</em> to create list values for statistical calculations.
+variation, quartiles, median, and 90th percentile.
+<p><em>v.db.univar</em> uses <em>db.select</em> to create list values for
+statistical calculations. This means that statistics are calculated based
+on the entries in the attribute table, not based on features. Each attribute
+value is read once per category present in the attribute table, even if there
+are more than one feature with the same category value. If a feature has more
+than one category value, and each of these are present in the attribute table,
+the attribute will be read once per category value. For feature-based, instead
+of attribute table-based, univariate statistics on attributes see
+<a href="v.univar.html">v.univar</a>.
+
<em>NOTES</em>
A database connection must be defined for the selected vector layer.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
