Do we really need v.db.univar ? Does it provide anything else/better than v.univar ?
Just to avoid module bloat and maybe rationalize when possible.
Moritz
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
Do we really need v.db.univar ? Does it provide anything else/better than
v.univar ?Just to avoid module bloat and maybe rationalize when possible.
+1 but mayI cite you... 
https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html
(copy below)
Since sime time passed, we may indeed want to revisit the topic.
ciao, Markus
On Mon, Jan 28, 2008 at 1:50 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 27/01/08 20:30, Michael Barton wrote:
v.univar only works with points. But since it is calculating stats on a
field in the attributes table, it should work the same for all vector
objects. Can we get rid of the limitation that it only works with points?There was some debate [1] about the statistical validity of working with the
other types, as the way it was programmed, the statistics were calculated
with weights which corresponded to line length / area surface .I guess we might want to distinguish between a v.univar which works on the
actual vector objects from a v.db.univar which works on any arbitrary
attribute (or combination of attributes). We could write a C-replacement of
the current v.db.univar script on the base of the code I have for the
classification algorithms used in v.class.As mentioned earlier, it might be better that I move the code from v.class
into a library which can then be accessed by different modules...Currently, I have defined the following statistics:
typedef struct
{
double count;
double min;
double max;
double sum;
double sumsq;
double mean;
double var;
double stdev;
} STATS;But this could easily be extended according to needs and v.db.univar could
also use the quantile classification algorithm to extract percentiles.What are the statistics most people need ?
Moritz
[1] http://lists.osgeo.org/pipermail/grass-dev/2004-July/014976.html
On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:Do we really need v.db.univar ? Does it provide anything else/better than
v.univar ?Just to avoid module bloat and maybe rationalize when possible.
+1 but mayI cite you...
https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html
(copy below)
It's always good to be reminded of the things one said in the past. 
However, the module has evolved quite a lot since that discussion, and in the direction contrary to what I said in terms of distinguishing the two.
At this stage, I don't see anything in v.db.univar that is not also provided by v.univar, but v.univar provides more options than v.db.univar. And since v.univar is C, I would suggest keeping that module.
Its man page needs some love, however, as I have the feeling that not all info is correct. Notably:
"When using the -d flag, univariate statistics of vector geometry are calculated. Depending on the selected vector type, distances are calculated as follows:
type=point: point distances are considered;
type=line: the first point of each line is considered;
type=area: the centroid of each area is considered."
but type=area actually creates a fatal error. You have to explicitely ask for type=centroid.
It might be interesting, in the long run, to output some general statistics on geometries (e.g. on area and perimeter for areas, on length for lines), but that would mean duplicating some of v.to.db's code...
Since sime time passed, we may indeed want to revisit the topic.
+1
Moritz
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@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.
v.univar can also compute statistics on the distances between vector geometries. There is no explanation in the manual what this should be good for. Markus N, you wanted this feature many years ago, do you remember why?
Markus M
Just to avoid module bloat and maybe rationalize when possible.
+1 but mayI cite you…
https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html
(copy below)It’s always good to be reminded of the things one said in the past.
However, the module has evolved quite a lot since that discussion, and in the direction contrary to what I said in terms of distinguishing the two.
At this stage, I don’t see anything in v.db.univar that is not also provided by v.univar, but v.univar provides more options than v.db.univar. And since v.univar is C, I would suggest keeping that module.
Its man page needs some love, however, as I have the feeling that not all info is correct. Notably:
"When using the -d flag, univariate statistics of vector geometry are calculated. Depending on the selected vector type, distances are calculated as follows:
type=point: point distances are considered;
type=line: the first point of each line is considered;
type=area: the centroid of each area is considered."but type=area actually creates a fatal error. You have to explicitely ask for type=centroid.
It might be interesting, in the long run, to output some general statistics on geometries (e.g. on area and perimeter for areas, on length for lines), but that would mean duplicating some of v.to.db’s code…
Since sime time passed, we may indeed want to revisit the topic.
+1
Moritz
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
On Wed, Jun 21, 2017 at 10:19 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
...
v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this should be good
for. Markus N, you wanted this feature many years ago, do you remember why?
I found this related ticket:
https://trac.osgeo.org/grass/ticket/942
Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then... and needed to know the average distance between points in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).
However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.
markusN
On 6/21/17 11:12 PM, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 10:19 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
...v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this should be good
for. Markus N, you wanted this feature many years ago, do you remember why?I found this related ticket:
https://trac.osgeo.org/grass/ticket/942Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then... and needed to know the average distance between points in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.
+1
markusN
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@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
(attachments)
v.univar.html.diff (1.8 KB)
v.db.univar.html.diff (1.38 KB)
On 21/06/17 23:12, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 10:19 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
...v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this should be good
for. Markus N, you wanted this feature many years ago, do you remember why?I found this related ticket:
https://trac.osgeo.org/grass/ticket/942Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then... and needed to know the average distance between points in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.
Would this possibly be better done within v.distance ? Something like a -s flag meaning "Output summary statistics of desired information" which would take the info chosen in upload=, and possibly the -a flag and calculated summary statistics ?
Moritz
On Thu, Jun 22, 2017 at 10:56 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 21/06/17 23:12, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 10:19 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
…v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this should be good
for. Markus N, you wanted this feature many years ago, do you remember why?I found this related ticket:
https://trac.osgeo.org/grass/ticket/942Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then… and needed to know the average distance between points
Did you really want to average distance to all other points or rather the average distance to the nearest other point?
in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.Would this possibly be better done within v.distance ? Something like a -s flag meaning “Output summary statistics of desired information” which would take the info chosen in upload=, and possibly the -a flag and calculated summary statistics ?
v.distance uses the distance to the nearest feature while v.univar uses all distances to all other features. While v.distance makes sense to me, v.univar’s distances to all other features do not make sense to me.
Markus M
On 22/06/17 11:43, Markus Metz wrote:
On Thu, Jun 22, 2017 at 10:56 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:On 21/06/17 23:12, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 10:19 PM, Markus Metz
<markus.metz.giswork@gmail.com<mailto:markus.metz.giswork@gmail.com>> wrote:
...
v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this shouldbe good
for. Markus N, you wanted this feature many years ago, do you
remember why?
I found this related ticket:
https://trac.osgeo.org/grass/ticket/942Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then... and needed to know the average distance between pointsDid you really want to average distance to all other points or rather
the average distance to the nearest other point?in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz <http://r.in.xyz> and count the points falling into eachraster cell, then
r.univar on the resulting map).
However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.Would this possibly be better done within v.distance ? Something like
a -s flag meaning "Output summary statistics of desired information"
which would take the info chosen in upload=, and possibly the -a flag
and calculated summary statistics ?v.distance uses the distance to the nearest feature while v.univar uses
all distances to all other features.
v.distance -a also provides this.
While v.distance makes sense to me,
v.univar's distances to all other features do not make sense to me.
Although, I don't have a specific use case at this stage, I do think that these can be a potentially interesting variables to geometrically characterize a layer, for example a point layer for which this would be a measure of general dispersal, especially when looking not only at the average.
Moritz
On Jun 22, 2017 11:43 AM, “Markus Metz”
On 21/06/17 23:12, Markus Neteler wrote:
…
Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then… and needed to know the average distance between pointsDid you really want to average distance to all other points or rather the average distance to the nearest other point?
Indeed the latter…
in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.Would this possibly be better done within v.distance ? Something like a -s flag meaning “Output summary statistics of desired information” which would take the info chosen in upload=, and possibly the -a flag and calculated summary statistics ?
v.distance uses the distance to the nearest feature while v.univar uses all distances to all other features. While v.distance makes sense to me, v.univar’s distances to all other features do not make sense to me.
I agree.
markusN
Both could be useful. For example, when looking at dispersal distances to seed sources in a landscape you may be interested in the nearest neighbors, but also all available seed sources in a landscape.
···
On 6/22/17 1:39 PM, Markus Neteler wrote:
On Jun 22, 2017 11:43 AM, “Markus Metz”
On 21/06/17 23:12, Markus Neteler wrote:
…
Checking further, I found a personal wish email to MartinL from 2009.
AFAIR I was dealing with LiDAR point clouds of the Trentino back
then… and needed to know the average distance between pointsDid you really want to average distance to all other points or rather the average distance to the nearest other point?
Indeed the latter…
in
order to optimize raster binning (meanwhile I would probably use
r.in.xyz and count the points falling into each raster cell, then
r.univar on the resulting map).However, to have the possibility to compute statistics on the
distances between vector (point) geometries makes sense to me in a
GIS.Would this possibly be better done within v.distance ? Something like a -s flag meaning “Output summary statistics of desired information” which would take the info chosen in upload=, and possibly the -a flag and calculated summary statistics ?
v.distance uses the distance to the nearest feature while v.univar uses all distances to all other features. While v.distance makes sense to me, v.univar’s distances to all other features do not make sense to me.
I agree.
markusN
_______________________________________________ grass-dev mailing list [grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org) [https://lists.osgeo.org/mailman/listinfo/grass-dev](https://lists.osgeo.org/mailman/listinfo/grass-dev)
On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@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.
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.
v.db.univar uses db.univar, not db.select, that’s an error in the existing manual.
I suggest to update the manuals first, then decide if the modules should be modified.
Markus M
On 22/06/17 14:21, Markus Metz wrote:
On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be><mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.worldonline.be>>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be><mailto:mlennert@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
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
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be><mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.worldonline.be>>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be><mailto:mlennert@club.worldonline.be
<mailto:mlennert@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.
Moritz
On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert <mlennert@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
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)>
wrote:On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)<mailto:mlennert@club.worldonline.be
mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)<mailto:mlennert@club.worldonline.be
mailto:[mlennert@club.worldonline.be](mailto:mlennert@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
Le 23 juin 2017 08:38:43 GMT+02:00, Markus Metz <markus.metz.giswork@gmail.com> a écrit :
On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert <
mlennert@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
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>>
wrote:
On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>
<mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.worldonline.be>>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>
<mailto:mlennert@club.worldonline.be
<mailto:mlennert@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
On 24/06/17 09:49, Moritz Lennert wrote:
Le 23 juin 2017 08:38:43 GMT+02:00, Markus Metz <markus.metz.giswork@gmail.com> a écrit :
On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert <
mlennert@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
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>>
wrote:
On 21/06/17 22:19, Markus Metz wrote:
On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>
<mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.worldonline.be>>> wrote:On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert@club.worldonline.be<mailto:mlennert@club.worldonline.be>
<mailto:mlennert@club.worldonline.be
<mailto:mlennert@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.
Done in r71224.
Moritz