Tue, Jul 9 2002
15:19:30
|
|
Request created by guest
|
|
Subject: grass5.1 d.vect doesn't show all lines falling within zoomed display
Apparently if a 2D vector has at least one of its end points within the active
display area, whole visible subsegment is shown successfully.
When a subsegment just intersects the display area and both its end points are
outside, either the line is not drawn at all, or is drawn with wrong colour.
This appears with Grass 5.1 d.vect from CVS of about a week ago.
This shows symptoms of classical computer graphics vector visibility problem,
and should be fairly easy to fix by following algorithms in basic computer
graphics books. (Unfortunately I have misplaced my reference books, and can't
fix it right away.)
Does it happen with 5.0, I have not verified. I have used 5.1's 3D vectors to
model various buildings and other constructs at a hilltop.
|
|
Tue, Jul 9 2002
15:44:22
|
|
Mail sent by guest
|
|
Cannot confirm. Both 2D/3D work for me.
Radim
|
|
Wed, Jul 10 2002
15:16:55
|
|
Comments added by guest
|
|
Initially I observed this at a black base X display, where I drew some
boundary lines, and measured site spots. When zooming in, some of those
boundary lines disappeared.
I have a 2D vertex set:
L 7
497.420 398.156
593.463 425.459
533.600 517.400
548.360 613.690
509.920 669.000
440.770 593.270
497.420 398.156
Working initially at g.region w=0 s=0 n=1000 e=1000 res=0.1, inputting
that set with v.in.ascii, and then plotting this on GRAY background:
d.erase color=gray
d.vect map=testset-1 color=red
Now change the displayed region:
g.region n=580 s=448 w=470 e=650 res=0.1
d.redisplay
and you should see what I mean.
It is possible that lines which are merely intersecting the visibility
region are drawn with BLACK color, instead of set color (RED).
The more I am playing with the case, the more I suspect this is an issue
with plotted vertex color becoming BLACK at odd moments. I just had a case
where one building outline line set became completely black, while being
fully inside the visibility area.
And of course, nothing excludes (so far) a possibility of this being
a compiler bug:
gcc version 3.1 20020619 (Red Hat Linux Rawhide 3.1-6.1)
...
successive d.redraw runs cycled the building outline in question from
all in correct color, to progressingly more in wrong color -- AND again
all in correct color.. |
|
Wed, Jul 10 2002
16:20:12
|
|
Mail sent by guest
|
|
I have got:
http://mpa.itc.it/radim/draw1.png
http://mpa.itc.it/radim/draw2.png
in grass5.1/grass5.
May be also bug in grass, which appears only in gcc 3.1.
Last 3 rows of your last reply, I don't understand.
(maybe report as new bug in grass50)
Radim
|
|
Tue, Jul 16 2002
11:36:18
|
|
Area changed to grass5.1 by bernhard
|
|
Wed, Jan 22 2003
10:50:22
|
|
Mail sent by mneteler
|
|
Hi
does this problem still exist?
Markus |
|
Mon, Aug 25 2003
16:50:15
|
|
Mail sent by mneteler
|
|
Today's status:
Unfortunately this problem is still there.
Probably the clipping algorithm when drawing a map?
v.digit shows it as well.
Reproducable in XDRIVER and PNG driver.
Markus
|
|
Mon, Oct 20 2003
18:14:15
|
|
Area changed to grass5.7 by mneteler
|
|
Mon, Aug 2 2004
13:14:58
|
|
Comments added by guest
|
|
If you underlay a raster for reference, is the clipping actually just the
extent of the region when the display monitor and region settings have
different aspect ratios? I saw something similar when digitizing lines with
5.7's v.digit with a big null border on either side. Had me confused for a while.
Hamish
|
|
Sat, Jul 23 2005
12:39:56
|
|
Mail sent by msieczka
|
|
Matti (or anybody)
Does this problem still exist in 6.0 or 6.1?
Maciek
Please "reply to all" so I receive a copy directly. |
|
Wed, Aug 31 2005
13:40:00
|
|
Status changed to resolved by msieczka
|
|
Wed, Aug 31 2005
13:40:00
|
|
Mail sent by msieczka
|
|
Apparently resolved as nobody's answered within 1,5 month. Closing it. Please
let me know if I should reopen.
Maciek |
|