this bug's URL: http://intevation.de/rt/webrt?serial_num=2664
-------------------------------------------------------------------------
Subject: r.contour writes negative elevations to category
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 5.7cvs20041009
r.contour puts the contour elevations in the category. A minor drawback is that this rounds any
fractional elevation values to integers, so is useless for fine detail contouring. The big problem is
that it will write negative categories, which I'm told is wrong.
r.contour should write elevations to a table. It does put the elevations in the z (height) of the
vector, but there doesn't seem to be a height option to v.to.db (just length and area). That would be
the other solution - maybe easier to do.
-------------------------------------------- Managed by Request Tracker
On Thursday 14 October 2004 19:06, Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=2664
-------------------------------------------------------------------------
Subject: r.contour writes negative elevations to category
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 5.7cvs20041009
r.contour puts the contour elevations in the category. A minor drawback is
that this rounds any fractional elevation values to integers, so is useless
for fine detail contouring. The big problem is that it will write negative
categories, which I'm told is wrong.
r.contour should write elevations to a table. It does put the elevations
in the z (height) of the vector, but there doesn't seem to be a height
option to v.to.db (just length and area). That would be the other solution
- maybe easier to do.
Now it writes a table with levels.
WARNING: cats are not level values any more!
Radim
Cool. But, slight problem - the cat values used in the vectors ranges from 1..n, while the cat values used in the table range from 0..n-1 (n being the number of unique levels from r.contour). So all the contours get shifted up 1 level, and the upper contours have no db record.
On Oct 18, 2004, at 8:54 AM, Radim Blazek wrote:
On Thursday 14 October 2004 19:06, Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=2664
-------------------------------------------------------------------------
Subject: r.contour writes negative elevations to category
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 5.7cvs20041009
r.contour puts the contour elevations in the category. A minor drawback is
that this rounds any fractional elevation values to integers, so is useless
for fine detail contouring. The big problem is that it will write negative
categories, which I'm told is wrong.
r.contour should write elevations to a table. It does put the elevations
in the z (height) of the vector, but there doesn't seem to be a height
option to v.to.db (just length and area). That would be the other solution
- maybe easier to do.
Now it writes a table with levels.
WARNING: cats are not level values any more!
Radim
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/
First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?
-HitchHiker's Guide to the Galaxy
On Monday 18 October 2004 18:16, William K wrote:
Cool. But, slight problem - the cat values used in the vectors ranges
from 1..n, while the cat values used in the table range from 0..n-1 (n
being the number of unique levels from r.contour). So all the contours
get shifted up 1 level, and the upper contours have no db record.
Thanks. Fixed.
Radim