On 21/06/17 14:57, Markus Neteler wrote:
On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlenn...@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
