[GRASS-dev] [bug #5259] (grass) reply to Hamish on Ticket 5254: enable v.what to report on more than one category

Request Tracker grass-bugs at intevation.de
Sat Nov 4 10:46:50 EST 2006

this bug's URL: http://intevation.de/rt/webrt?serial_num=5259

>> I don't know how often situations like this might arise, however...
>> I have a database with over 75000 records (~30 fields/record) which is
> >poorly georeferenced (it uses an odd alpha-numeric mapping reference
>> involving map book pages, etc), such that locations can be defined
>> only to the nearest 1km by 1km area. I have calculated UTM centered on
> >the 1 km squares for each record using a spreadsheed. These 75000
> >records imported into Grass result in approx. 12500 points (too much
> >data to sort on a spreadsheet).
>> While some data points may contain as many as 20 categories, it
> >appears that v.what can report on only one category (the first one
> >encountered?). It would be nice if v.what could "drill through" all
> >categories at each point to report all data. In addition, it would be
> >nice if a new Grass module could be developed to allow functions like
> >mean, max, min, etc., to be done for the various fields available in
> >this too-many-categories-per-point database, in which case some very
> >useful surface maps could be produced.
> >I do not write code and so cannot contribute directly to development,
> >but I introduce the concept here in the hope that someone who can
> >write might find this change to v.what and/or a new function handy. I
> >am willing to make parts of the database available for such
> >development and can participate in testing.

> does v.perturb help to get the points directly off the top of one
> another? if error is +/- 500m anyway, introducing a few cm won't harm..

> Hamish

Hamish, thanks for your quick reply.

I tried to respond via the bugtracking system, but my reply for some reason=
does not appear on the Web page. Thus this email to you.

I have tried v.perturb and I can "unstack" the data points nicely so to be =
able to query each individually while keeping spatial error low. However, =20
this requires clicking on each point individually instead of being able to =
produce a display or printed records of all data at that location. Thus my =
wish to "drill" through the data at each location as one item.

This database is large, with over 75000 records (~30 attributes per record)=
and point "stacks" at over 12500 locations, with 1 point only in the stack =
at =20
some locations, but over 50 in the stack at others. These "stacks" are =20
compilations of records which were known to be present within given 1km^2 =20
areas, but for which no better georeferencing is available. Thus my decisio=
n =20
to center data (point) "stacks" within 1km squares.

What I need to do with this data is to find count, max, min, mode, median, =
average, std, etc. for a number of attributes for the stacked sets of point=
s, =20
from which I could then do surfaces to analyze the data. If something like =
r.neighbor existed for work on vectors (points), then I could accomplish th=
is =20
following a v.perturb. I cannot do v.to.rast and then apply r.neighbor or =20
v.neighbour, as the conversion to raster of over 50 points into a raster wi=
th =20
25m by 25m cells would result in lost data and/or too large and inconsisten=
t =20
(uncontrolled) spatial error.

I am guessing that data analysis situations such as mine must arise fairly =
frequently. Thus my wish for a new Grass module (v.neighbor2 perhaps?). One=
that could perhaps (after doing v.perturb) report statistics on points on o=
ne =20
vector map surrounding a certain distance around points on another vector m=
ap =20
(note that points could also read "line" or "area")?


--- Headers Follow ---

>From rg-ewc at waterwatch.com  Sat Nov  4 16:46:50 2006
Return-Path: <rg-ewc at waterwatch.com>
Delivered-To: grass-bugs at lists.intevation.de
Received: from kolab.intevation.de (aktaia [])
	by lists.intevation.de (Postfix) with ESMTP id BF2C4101F00
	for <grass-bugs at lists.intevation.de>; Sat,  4 Nov 2006 16:46:50 +0100 (CET)
Received: from localhost (localhost.localdomain [])
	by kolab.intevation.de (Postfix) with ESMTP id A6ED81139C1
	for <grass-bugs at lists.intevation.de>; Sat,  4 Nov 2006 16:46:50 +0100 (CET)
Received: from localhost (localhost.localdomain [])
	by kolab.intevation.de (Postfix) with ESMTP id 7BDDA1858B8
	for <grass-bugs at lists.intevation.de>; Sat,  4 Nov 2006 16:46:50 +0100 (CET)
Received: from simmts6-srv.bellnexxia.net (simmts6.bellnexxia.net [])
	by kolab.intevation.de (Postfix) with ESMTP id 144771139C1
	for <grass-bugs at intevation.de>; Sat,  4 Nov 2006 16:46:48 +0100 (CET)
Received: from rick3.ewc ([]) by simmts6-srv.bellnexxia.net
          (InterMail vM. 201-253-122-130-113-20050324) with ESMTP
          id <20061104154642.XCLS25660.simmts6-srv.bellnexxia.net at rick3.ewc>
          for <grass-bugs at intevation.de>; Sat, 4 Nov 2006 10:46:42 -0500
Date: Sat, 04 Nov 2006 11:46:41 -0400
From: "Richard Gagne P.Geo." <rg-ewc at waterwatch.com>
Reply-To: rg-ewc at waterwatch.com
Subject: reply to Hamish on Ticket 5254: enable v.what to report on more
 than one category
To: grass-bugs at intevation.de
X-Mailer: Balsa 2.3.12
Message-Id: <1162655201l.2446l.0l at rick3.ewc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by amavisd-new at intevation.de
X-Spam-Status: No, hits=-4.961 tagged_above=-999 required=3
 tests=[BAYES_00=-5, MIME_QP_LONG_LINE=0.039]

-------------------------------------------- Managed by Request Tracker

More information about the grass-dev mailing list