Fri, Nov 3 2006
05:57:20
|
|
Request created by guest
|
|
Subject: enable v.what to report on more that one category
Platform: GNU/Linux/x86
A wish for Grass 6.3?
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.
Regards,
Rick |
|
Fri, Nov 3 2006
06:36:57
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 3 Nov 2006 18:36:45 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5254] (grass) enable v.what to report on more that one category
|
Message-Id |
<20061103183645.24d4bb8f.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061103045720.0A9E21006AB@lists.intevation.de>
|
References |
<20061103045720.0A9E21006AB@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5254
> ---------------------------------------------------------------------
>
> Subject: enable v.what to report on more that one category
>
> Platform: GNU/Linux/x86
> A wish for Grass 6.3?
>
> 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
|
|
Sat, Nov 4 2006
16:46:50
|
|
Request created by rg-ewc@waterwatch.com (as #5259)
|
|
Return-Path |
<rg-ewc@waterwatch.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
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 |
|
>> 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
|
|
Sun, Nov 5 2006
06:51:19
|
|
Mail sent by hamish_nospam@yahoo.com (as #5259)
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Sun, 5 Nov 2006 18:51:12 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] [bug #5259] (grass) reply to Hamish on Ticket 5254: enable v.what to report on more than one category
|
Message-Id |
<20061105185112.6c48c4df.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061104154650.EA0CE101F01@lists.intevation.de>
|
References |
<20061104154650.EA0CE101F01@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
|
X-Spam-Level |
|
Request Tracker wrote:
>
> 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 points,
May I suggest using r.in.xyz on the point data with appropriately
designed g.region settings.
Hamish
|
|
Sun, Nov 5 2006
14:01:19
|
|
Request 5259 merged into 5254 by msieczka (as #5259)
|
|