this bug's URL: http://intevation.de/rt/webrt?serial_num=5259
-------------------------------------------------------------------------
I don't know how often situations like this might arise, however...
=20
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).=20
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.=20
>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=
=20
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 =
=20
able to query each individually while keeping spatial error low. However, =20
this requires clicking on each point individually instead of being able to =
=20
produce a display or printed records of all data at that location. Thus my =
=20
wish to "drill" through the data at each location as one item.
This database is large, with over 75000 records (~30 attributes per record)=
=20
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, =
=20
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 =
=20
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 =
=20
frequently. Thus my wish for a new Grass module (v.neighbor2 perhaps?). One=
=20
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")?
Regards,
Rick
--- Headers Follow ---
From rg-ewc@waterwatch.com Sat Nov 4 16:46:50 2006
Return-Path: <rg-ewc@waterwatch.com>
Delivered-To: grass-bugs@lists.intevation.de
Received: from kolab.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP id BF2C4101F00
for <grass-bugs@lists.intevation.de>; Sat, 4 Nov 2006 16:46:50 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
by kolab.intevation.de (Postfix) with ESMTP id A6ED81139C1
for <grass-bugs@lists.intevation.de>; Sat, 4 Nov 2006 16:46:50 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
by kolab.intevation.de (Postfix) with ESMTP id 7BDDA1858B8
for <grass-bugs@lists.intevation.de>; Sat, 4 Nov 2006 16:46:50 +0100 (CET)
Received: from simmts6-srv.bellnexxia.net (simmts6.bellnexxia.net [206.47.199.164])
by kolab.intevation.de (Postfix) with ESMTP id 144771139C1
for <grass-bugs@intevation.de>; Sat, 4 Nov 2006 16:46:48 +0100 (CET)
Received: from rick3.ewc ([142.167.245.179]) by simmts6-srv.bellnexxia.net
(InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP
id <20061104154642.XCLS25660.simmts6-srv.bellnexxia.net@rick3.ewc>
for <grass-bugs@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@waterwatch.com>
Reply-To: rg-ewc@waterwatch.com
Subject: reply to Hamish on Ticket 5254: enable v.what to report on more
than one category
To: grass-bugs@intevation.de
X-Mailer: Balsa 2.3.12
Message-Id: <1162655201l.2446l.0l@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]
X-Spam-Level:
-------------------------------------------- Managed by Request Tracker