Fri, Dec 3 2004
14:19:26
|
|
Request created by guest
|
|
Subject: v.buffer produces strange results
Platform: GNU/Linux/i386
grass obtained from: Other (CDROM etc)
grass binary for platform: Downloaded precompiled Binaries
When trying to create a new buffer theme with v.buffer (polygon theme), I got
strange results when using different buffer distances: small buffer distances
worked quite good, but at a certain buffer distance, the shape of the new buffer
theme was completely different compared to the input vector theme.
I used the following syntax to create the buffer theme:
v.buffer in=polygonmap out=polygonmap_buf buffer=buffer_distance
|
|
Fri, Dec 3 2004
14:42:07
|
|
Mail sent by blazek@itc.it
|
|
Return-Path |
<blazek@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<41B06D29.1080305@itc.it>
|
Date |
Fri, 03 Dec 2004 14:42:01 +0100
|
From |
Radim Blazek <blazek@itc.it>
|
User-Agent |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2765] (grass) v.buffer produces strange results
|
References |
<20041203131926.15F05102C25@lists.intevation.de>
|
In-Reply-To |
<20041203131926.15F05102C25@lists.intevation.de>
|
Content-Type |
text/plain; charset=us-ascii; format=flowed
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2765
> -------------------------------------------------------------------------
>
> Subject: v.buffer produces strange results
>
> Platform: GNU/Linux/i386
> grass obtained from: Other (CDROM etc)
> grass binary for platform: Downloaded precompiled Binaries
>
> When trying to create a new buffer theme with v.buffer (polygon theme), I got
strange results when using different buffer distances: small buffer distances
worked quite good, but at a certain buffer distance, the shape of the new buffer
theme was completely different compared to the input vector theme.
> I used the following syntax to create the buffer theme:
> v.buffer in=polygonmap out=polygonmap_buf buffer=buffer_distance
>
Can you extract one feature and sentd it to me? However, v.buffer should
be rewritten partialy, I cannot promise anything soon.
Radim
|
|
Mon, Feb 28 2005
21:37:30
|
|
Area changed to grass6 by pcavallini
|
|
Mon, Feb 28 2005
21:38:55
|
|
Comments added by pcavallini
|
|
Temporary workaround:
apply v.buffer with smaller radius several times until reaching the desired
buffe size.
pc |
|
Tue, Jul 18 2006
18:25:03
|
|
Request created by guest (as #4869)
|
|
Subject: v.buffer: corruted output on a very simple input
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-07-10
I know v.buffer has problems and limitations, but such one I haven't seen yet.
See:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/corrupted_buffer_of_a_line.png
Green is the input vector line, black and grey is the output of:
v.buffer input=frame output=frame_buf type=line buffer=30
The input feature is very simple, yet the v.buffer output is a complete mess.
I'm affraid we can't rely on v.buffer for anything besides buffering points.
Maciek
|
|
Sun, Jul 23 2006
20:13:14
|
|
User changed to tutey@o2.pl by msieczka (as #4869)
|
|
Tue, Jul 25 2006
00:30:47
|
|
Comments added by guest (as #4869)
|
|
Maybe this is the key to the v.buffer problem?
Markus |
|
Wed, Aug 2 2006
21:17:12
|
|
Mail sent by guest
|
|
Testing in spearfish, using 2006-07-31 cvs:
v.buffer input=railroads output=railroads_buffer_500 buffer=500
v.buffer input=railroads output=railroads_buffer_2000 buffer=2000
v.buffer input=railroads output=railroads_buffer_5000 buffer=5000
v.buffer input=railroads output=railroads_buffer_10000 buffer=10000
v.buffer input=railroads output=railroads_buffer_20000 buffer=20000
v.buffer input=railroads output=railroads_buffer_40000 buffer=40000
v.buffer input=railroads output=railroads_buffer_80000 buffer=80000
v.buffer input=railroads output=railroads_buffer_100000 buffer=100000
v.buffer input=railroads output=railroads_buffer_200000 buffer=200000
All produce buffers that look normal. As the buffer parameter increases, the
outline of the buffer will tend to converge on the shape of a circle. I also
tried buffering the soils vector but couldn't reproduce anything abnormal. I
think we need a specific test case from the original poster to confirm. I
couldn't reproduce this error.
~ Eric.
<epatton at nrcan dot gc dot ca> |
|
Wed, Aug 2 2006
22:02:42
|
|
Comments added by msieczka (as #4869)
|
|
Cc: neteler@itc.it
guest wrote (Tue, Jul 25 2006 00:30:47):
> Maybe this is the key to the v.buffer problem?
What do you mean?
Or maybe that's just an irony aginst my jumpy tone (I won't argue I don't
deserve it, at least some ;)).
Maciek
|
|
Wed, Aug 2 2006
22:07:53
|
|
Mail sent by neteler@itc.it (as #4869)
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 2 Aug 2006 22:07:51 +0200
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Subject |
Re: [bug #4869] (grass) v.buffer: corruted output on a very simple input
|
Message-ID |
<20060802200751.GG15803@bartok.itc.it>
|
References |
<20060802200242.C1E47101EFC@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20060802200242.C1E47101EFC@lists.intevation.de>
|
X-PGP-Key |
http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
|
X-PGP-Fingerprint |
D4D5 2F80 120E AD60 E2F6 2297 21B3 D02B E1E7 E789
|
User-Agent |
Mutt/1.5.11
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-3.886 tagged_above=-999 required=3 tests=[AWL=0.848, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
|
X-Spam-Level |
|
On Wed, Aug 02, 2006 at 10:02:42PM +0200, Maciek Sieczka via RT wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4869
>
> Request number 4869 was commented on by 'msieczka' (Maciek Sieczka).
> Responding to this message will send mail to the requestor.
>
> Request Tracker
> rt@intevation.de
>
> --------------------------------------------------------------
> Cc: neteler@itc.it
>
> guest wrote (Tue, Jul 25 2006 00:30:47):
>
> > Maybe this is the key to the v.buffer problem?
>
> What do you mean?
>
> Or maybe that's just an irony aginst my jumpy tone (I won't argue I don't
> deserve it, at least some ;)).
No irony at all.
With "key" I meant that the crossing lines probably indicate
the general problem of v.buffer which sporadically, with large
buffers, appears. But who knows. Just ignore my comment.
cheers
Markus
|
|
Fri, Aug 25 2006
05:22:39
|
|
Request 4869 merged into 2765 by hbowman (as #4869)
|
|
Fri, Aug 25 2006
05:22:54
|
|
Priority changed to 80 by hbowman
|
|
Wed, Sep 6 2006
14:49:21
|
|
Comments added by hbowman
|
|
in doc/vector/TODO, Radim wrote:
v.buffer
--------
Completely rewrite if possible or at least fix the bug which is
probably in clean_parallel() in lib/vector/Vlib/buffer.c.
|
|
Fri, Sep 8 2006
12:00:16
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 8 Sep 2006 22:00:01 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
grass5 <grass-dev@grass.itc.it>
|
Cc |
grass-bugs@intevation.de, tutey@o2.pl
|
Subject |
Re: [bug #2765] v.buffer bug??
|
Message-Id |
<20060908220001.7086d05c.hamish_nospam@yahoo.com>
|
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 |
|
Can someone provide me with a simple vector file where the buffering bug
happens? or make it happen with a Speafish map?
Maciek:
> http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/corrupted_buffer_of_a_line.png
thanks,
Hamish
|
|
Mon, Sep 11 2006
04:14:07
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 11 Sep 2006 14:13:56 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-dev@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [bug #2765] v.buffer bug??
|
Message-Id |
<20060911141356.6bc30ab3.hamish_nospam@yahoo.com>
|
In-Reply-To |
<4503E383.7030205@o2.pl>
|
References |
<20060908220001.7086d05c.hamish_nospam@yahoo.com> <4503E383.7030205@o2.pl>
|
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 |
multipart/mixed; boundary="Multipart=_Mon__11_Sep_2006_14_13_56_+1200_EHCfKg=4xglc40Sc"
|
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 |
|
This is a multi-part message in MIME format.
--Multipart=_Mon__11_Sep_2006_14_13_56_+1200_EHCfKg=4xglc40Sc
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
me:
> > Can someone provide me with a simple vector file where the buffering
> > bug happens? or make it happen with a Speafish map?
Maciek:
> In a message I just sent to you offlist you'll find an attached Grass
> location with 2 input vectors:
>
> square_rot
Notice this is not a square of four corners! If you zoom in you find it
contains 229 vertices, i.e. this is r.to.vect output with steps at the
grid resolution. So not as easy to debug by hand,
> ditches
I couldn't recreate your buff=1 and 4 errors- buffering works fine for
me there. I was however able to extract the attached problematic feature
(area 1188), which is a fairly simple example. I reimported the ascii
file as a new vector and got the same results, so hopefully others can
reproduce with this too (?). I tested with buff=4 and buff=10.
Using debug=buffer,clean didn't help, problem happens before that.
Hamish
--Multipart=_Mon__11_Sep_2006_14_13_56_+1200_EHCfKg=4xglc40Sc
Content-Type: application/octet-stream;
name="bad_buff.vasc"
Content-Disposition: attachment;
filename="bad_buff.vasc"
Content-Transfer-Encoding: base64
T1JHQU5JWkFUSU9OOiAKRElHSVQgREFURTogICAKRElHSVQgTkFNRTogICBqb2huCk1BUCBOQU1F
OiAgICAgT3V0cHV0IGZyb20gdi5wYXRjaApNQVAgREFURTogICAgIApNQVAgU0NBTEU6ICAgIDEK
T1RIRVIgSU5GTzogICAKWk9ORTogICAgICAgICAwCk1BUCBUSFJFU0g6ICAgMC4wMDAwMDAKVkVS
VEk6CkIgIDIKIDYwMDE2NS4xNTIxMDA5OSA1Njc4MzY5LjQ1MTUxODA2CiA2MDAwODYuNzQyNjc3
NzMgNTY3ODM5Ni41MzM3MjAxOApCICAzCiA2MDAwODYuNzQyNjc3NzMgNTY3ODM5Ni41MzM3MjAx
OAogNjAwMDc3Ljk3MzIwMjc2IDU2NzgzOTkuNjI4ODI4OTkKIDYwMDAzOS4wMjY0MTY4NiA1Njc4
NDA1LjM5OTkxNzMKQiAgMgogNjAwMTY3LjU3Mjg3MjQ1IDU2NzgzNjQuNDk2MDIxMzIKIDYwMDA4
NS40NTMwNDkwNSA1Njc4MzkyLjY2NDgzNDE2CkIgIDIKIDU5OTk0OS41MjYxODcwMSA1Njc4NDE5
LjQ4OTExMDU0CiA1OTk5NjguNjEyNjkxMzYgNTY3ODQxOC40NTc0MDc2CkIgIDIKIDU5OTk0OS41
MjYxODcwMSA1Njc4NDE5LjQ4OTExMDU0CiA1OTk5NTQuOTQyNjI3NDQgNTY3ODQxNC44NDY0NDcz
MwpCICAzCiA2MDAwMzYuNDQ3MTU5NTMgNTY3ODQwMS4zNjk4Mjc2NQogNjAwMDc3LjE5OTQyNTU1
IDU2NzgzOTYuMjc1Nzk0NDQKIDYwMDA4NS40NTMwNDkwNSA1Njc4MzkyLjY2NDgzNDE2CkIgIDIK
IDU5OTk2OC42MTI2OTEzNiA1Njc4NDE4LjQ1NzQwNzYKIDU5OTk5OC40MDMxMTM2OSA1Njc4NDEx
Ljc1MTMzODUxCkIgIDIKIDYwMDMzMy42Njg3Njc4NSA1Njc4MzE4LjUwMjIyODEzCiA2MDAzMjku
OTE4OTc2MTUgNTY3ODMyMS4yMzU5NTExNQpDICAxIDEKIDYwMDIzMi40MzY3NzY2OSA1Njc4MzQy
Ljk1MzQyNjMKIDEgICAgIDExODggICAgICAKQiAgMwogNjAwMzI5LjkxODk3NjE1IDU2NzgzMjEu
MjM1OTUxMTUKIDYwMDMyMS4xMjQxNjc0NCA1Njc4MzEzLjkyNTk4MDI4CiA2MDAxNjkuMjU3MTUy
MiA1Njc4MzY3Ljg2NDU4MDgyCkIgIDIKIDYwMDE2OS4yNTcxNTIyIDU2NzgzNjcuODY0NTgwODIK
IDYwMDE2NS4xNTIxMDA5OSA1Njc4MzY5LjQ1MTUxODA2CkIgIDgKIDU5OTk1NC45NDI2Mjc0NCA1
Njc4NDE0Ljg0NjQ0NzMzCiA1OTk5NjguMDEyNTgwODMgNTY3ODQxMy43Nzg2Nzk4NAogNTk5OTc5
Ljk2MTQyMzY4IDU2Nzg0MTIuMDA5MjY0MjQKIDU5OTk4Ny4xODMzNDQyNCA1Njc4NDEwLjcxOTYz
NTU3CiA1OTk5OTYuMjEwNzQ0OTQgNTY3ODQwOC4zOTgzMDM5NgogNjAwMDEwLjc4MzU0ODk1IDU2
Nzg0MDUuNjI1NjAyMjcKIDYwMDAzMC4zODU5MDQ3NyA1Njc4NDAyLjI3MjU2NzcyCiA2MDAwMzYu
NDQ3MTU5NTMgNTY3ODQwMS4zNjk4Mjc2NQpCICAyCiA2MDAwMDEuNjI4MDAyNDEgNTY3ODQxMS4x
OTQ1MjE0OQogNTk5OTk4LjQwMzExMzY5IDU2Nzg0MTEuNzUxMzM4NTEKQiAgMgogNjAwMDM5LjAy
NjQxNjg2IDU2Nzg0MDUuMzk5OTE3MwogNjAwMDAxLjYyODAwMjQxIDU2Nzg0MTEuMTk0NTIxNDkK
QiAgNAogNjAwMTY3LjU3Mjg3MjQ1IDU2NzgzNjQuNDk2MDIxMzIKIDYwMDMyMS4yMzEwMDk2OSA1
Njc4MzEwLjk4Nzc0OTI1CiA2MDAzMjQuNTk5NTY5MTkgNTY3ODMxMi4wMjQyMjkwOQogNjAwMzMz
LjY2ODc2Nzg1IDU2NzgzMTguNTAyMjI4MTMK
--Multipart=_Mon__11_Sep_2006_14_13_56_+1200_EHCfKg=4xglc40Sc--
|
|
Mon, Sep 11 2006
07:47:31
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 11 Sep 2006 17:47:17 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
grass-dev@grass.itc.it
|
Cc |
tutey@o2.pl, grass-bugs@intevation.de
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] v.buffer bug??
|
Message-Id |
<20060911174717.27b76a21.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060911141356.6bc30ab3.hamish_nospam@yahoo.com>
|
References |
<20060908220001.7086d05c.hamish_nospam@yahoo.com> <4503E383.7030205@o2.pl> <20060911141356.6bc30ab3.hamish_nospam@yahoo.com>
|
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 |
|
Hamish wrote:
> me:
> > > Can someone provide me with a simple vector file where the
> > > buffering bug happens? or make it happen with a Speafish map?
..
> I couldn't recreate your buff=1 and 4 errors- buffering works fine for
> me there. I was however able to extract the attached problematic
> feature (area 1188), which is a fairly simple example. I reimported
> the ascii file as a new vector and got the same results, so hopefully
> others can reproduce with this too (?). I tested with buff=4 and
> buff=10.
>
> Using debug=buffer,clean didn't help, problem happens before that.
Converting to line and cleaning out excess vertices doesn't help either.
Here is a simplified version of a problematic area:
("v.in.ascii -n format=standard")
B 26
600039.02641686 5678405.3999173
600077.97320276 5678399.62882899
600086.74267773 5678396.53372018
600165.15210099 5678369.45151806
600169.2571522 5678367.86458082
600321.12416744 5678313.92598028
600329.91897615 5678321.23595115
600333.66876785 5678318.50222813
600324.59956919 5678312.02422909
600321.23100969 5678310.98774925
600167.57287245 5678364.49602132
600085.45304905 5678392.66483416
600077.19942555 5678396.27579444
600036.44715953 5678401.36982765
600030.38590477 5678402.27256772
600010.78354895 5678405.62560227
599996.21074494 5678408.39830396
599987.18334424 5678410.71963557
599979.96142368 5678412.00926424
599968.01258083 5678413.77867984
599954.94262744 5678414.84644733
599949.52618701 5678419.48911054
599968.61269136 5678418.4574076
599998.40311369 5678411.75133851
600001.62800241 5678411.19452149
600039.02641686 5678405.3999173
C 1 1
600232.43677669 5678342.9534263
1 1188
adding a few debug statements to lib/vector/Vlib/buffer.c shows:
--> npoints = 26
--> side=0, added 41 points
--> dangle=0.283079, PI=3.141593
added 11 arc points
--> side=1, added 3 points
--> dangle=0.283079, PI=3.141593
in Vect_line_parallel():
For side=1, there are 73 points created by parallel_line(), which if
plotted describe the *correct* buffered boundaries that we want.
==> After clean_parallel() there are only 3 points left. <==
So the problem is in clean_parallel().
If I comment out the clean_parallel() call, a correct looking output map
is created, but this may lead to other problems later on...?
for the last loop in side 1, sa=0. after the following sa+1 and two
npn++ calls, the number of valid points from that pass ends up as 3.
if ( point_in_buf( origPoints, px, py, d ) ){ /* is loop in buffer ? */
npn=sa+1;
here is evolution of segments sa and sb. all debug messages are in
clean_parallel(). error happens when (sb - sa) != 2, ie when the segment
wraps back to the beginning of the polygon?
nareas=1
Areas buffers ... 100%
--> side 0
D0/0: clean_parallel(): npoints = 54, d = 10.000000, rm_end = 0
D0/0: current = 1, last = 2, lcount = 1
D0/0: //> no_overlap: sa=0 sb=2 first=0 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=1 sa=0 sb=2, lcount=1
D0/0: //> just before "move points down": npn=2
D0/0: current = 4, last = 5, lcount = 1
D0/0: //> no_overlap: sa=3 sb=5 first=3 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=53 sa=3 sb=5, lcount=1
D0/0: //> just before "move points down": npn=5
D0/0: current = 13, last = 14, lcount = 1
D0/0: //> no_overlap: sa=12 sb=14 first=12 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=52 sa=12 sb=14, lcount=1
D0/0: //> just before "move points down": npn=14
D0/0: current = 15, last = 16, lcount = 1
D0/0: //> no_overlap: sa=14 sb=16 first=14 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=51 sa=14 sb=16, lcount=1
D0/0: //> just before "move points down": npn=16
D0/0: current = 15, last = 17, lcount = 1
D0/0: //> no_overlap: sa=14 sb=17 first=14 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 4
D0/0: //> loop [centroid] is in buffer npn=50 sa=14 sb=17, lcount=1
D0/0: //> just before "move points down": npn=16
D0/0: current = 18, last = 19, lcount = 1
D0/0: //> no_overlap: sa=17 sb=19 first=17 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=48 sa=17 sb=19, lcount=1
D0/0: //> just before "move points down": npn=19
D0/0: current = 22, last = 23, lcount = 1
D0/0: //> no_overlap: sa=21 sb=23 first=21 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=47 sa=21 sb=23, lcount=1
D0/0: //> just before "move points down": npn=23
D0/0: current = 23, last = 24, lcount = 1
D0/0: //> no_overlap: sa=22 sb=24 first=22 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=46 sa=22 sb=24, lcount=1
D0/0: //> just before "move points down": npn=24
D0/0: current = 24, last = 25, lcount = 1
D0/0: //> no_overlap: sa=23 sb=25 first=23 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=45 sa=23 sb=25, lcount=1
D0/0: //> just before "move points down": npn=25
D0/0: current = 25, last = 26, lcount = 1
D0/0: //> no_overlap: sa=24 sb=26 first=24 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=44 sa=24 sb=26, lcount=1
D0/0: //> just before "move points down": npn=26
D0/0: current = 32, last = 33, lcount = 1
D0/0: //> no_overlap: sa=31 sb=33 first=31 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=43 sa=31 sb=33, lcount=1
D0/0: //> just before "move points down": npn=33
D0/0: current = 35, last = 36, lcount = 1
D0/0: //> no_overlap: sa=34 sb=36 first=34 np=54
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=42 sa=34 sb=36, lcount=1
D0/0: //> just before "move points down": npn=36
D0/0: //> after: npn=41
--> side 1
D0/0: clean_parallel(): npoints = 73, d = -10.000000, rm_end = 0
D0/0: current = 1, last = 71, lcount = 1
D0/0: current = 3, last = 4, lcount = 2
D0/0: //> no_overlap: sa=2 sb=4 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=1 sa=2 sb=4, lcount=2
D0/0: //> just before "move points down": npn=4
D0/0: current = 1, last = 70, lcount = 1
D0/0: current = 6, last = 7, lcount = 2
D0/0: //> no_overlap: sa=5 sb=7 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=72 sa=5 sb=7, lcount=2
D0/0: //> just before "move points down": npn=7
D0/0: current = 1, last = 69, lcount = 1
D0/0: current = 7, last = 8, lcount = 2
D0/0: //> no_overlap: sa=6 sb=8 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=71 sa=6 sb=8, lcount=2
D0/0: //> just before "move points down": npn=8
D0/0: current = 1, last = 68, lcount = 1
D0/0: current = 29, last = 30, lcount = 2
D0/0: //> no_overlap: sa=28 sb=30 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=70 sa=28 sb=30, lcount=2
D0/0: //> just before "move points down": npn=30
D0/0: current = 1, last = 67, lcount = 1
D0/0: current = 32, last = 33, lcount = 2
D0/0: //> no_overlap: sa=31 sb=33 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=69 sa=31 sb=33, lcount=2
D0/0: //> just before "move points down": npn=33
D0/0: current = 1, last = 66, lcount = 1
D0/0: current = 41, last = 42, lcount = 2
D0/0: //> no_overlap: sa=40 sb=42 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=68 sa=40 sb=42, lcount=2
D0/0: //> just before "move points down": npn=42
D0/0: current = 1, last = 65, lcount = 1
D0/0: current = 42, last = 43, lcount = 2
D0/0: //> no_overlap: sa=41 sb=43 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=67 sa=41 sb=43, lcount=2
D0/0: //> just before "move points down": npn=43
D0/0: current = 1, last = 64, lcount = 1
D0/0: current = 43, last = 44, lcount = 2
D0/0: //> no_overlap: sa=42 sb=44 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=66 sa=42 sb=44, lcount=2
D0/0: //> just before "move points down": npn=44
D0/0: current = 1, last = 63, lcount = 1
D0/0: current = 60, last = 61, lcount = 2
D0/0: //> no_overlap: sa=59 sb=61 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=65 sa=59 sb=61, lcount=2
D0/0: //> just before "move points down": npn=61
D0/0: current = 1, last = 62, lcount = 1
D0/0: current = 61, last = 62, lcount = 2
D0/0: //> no_overlap: sa=60 sb=62 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 3
D0/0: //> loop [centroid] is in buffer npn=64 sa=60 sb=62, lcount=2
D0/0: //> just before "move points down": npn=62
D0/0: current = 1, last = 61, lcount = 1
D0/0: //> no_overlap: sa=0 sb=61 first=0 np=73
D0/0: //> add sPoint->n = 1
D0/0: //> after loop sPoint->n = 62
D0/0: //> loop [centroid] is in buffer npn=63 sa=0 sb=61, lcount=1
D0/0: //> just before "move points down": npn=2
D0/0: //> after: npn=3
nisles=0
Hamish
|
|
Mon, Sep 11 2006
21:44:00
|
|
Mail sent by msieczka
|
|
hamish_nospam@yahoo.com wrote (Mon, Sep 11 2006 04:14:07):
> Maciek:
>> square_rot
> Notice this is not a square of four corners!
Why the "!", actually?
> If you zoom in you find it contains 229 vertices, i.e. this is r.to.vect
> output with steps at the grid resolution. So not as easy to debug by hand
OK. But this doesn't mean buffering it should be buggy, right?
>> ditches
> I couldn't recreate your buff=1 and 4 errors- buffering works fine for
> me there.
I'm wondering why, because I can perfecetly reproduce the bug at any time with
exactly the data I sent you.
Are you absolutely sure that the output of following v.buffer commands:
v.buffer input=ditches output=ditches_buf1 type=area buffer=1
v.buffer input=ditches output=ditches_buf4 type=area buffer=4
looks all OK after you zoom to region 'ditches_buf' included in my sample dataset?
For me it's obvious that the output is plain wrong.
Maciek
|
|
Tue, Sep 12 2006
05:29:38
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 12 Sep 2006 15:29:18 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20060912152918.77a48f94.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060911194400.1FD111005B4@lists.intevation.de>
|
References |
<20060911194400.1FD111005B4@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 |
multipart/mixed; boundary="Multipart=_Tue__12_Sep_2006_15_29_18_+1200_6VmhFaX/IeDFNAvu"
|
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 |
|
This is a multi-part message in MIME format.
--Multipart=_Tue__12_Sep_2006_15_29_18_+1200_6VmhFaX/IeDFNAvu
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2765
> > Maciek:
> >> square_rot
>
> > Notice this is not a square of four corners!
>
> Why the "!", actually?
>
> > If you zoom in you find it contains 229 vertices, i.e. this is
> > r.to.vect output with steps at the grid resolution. So not as easy
> > to debug by hand
>
> OK. But this doesn't mean buffering it should be buggy, right?
This is significant as the bug appears on a complex polygon, not a
simple 4 vertex square as it appeared on first look.
> >> ditches
>
> > I couldn't recreate your buff=1 and 4 errors- buffering works fine
> > for me there.
>
> I'm wondering why, because I can perfecetly reproduce the bug at any
> time with exactly the data I sent you.
>
> Are you absolutely sure that the output of following v.buffer
> commands:
>
> v.buffer input=ditches output=ditches_buf1 type=area buffer=1
> v.buffer input=ditches output=ditches_buf4 type=area buffer=4
>
> looks all OK after you zoom to region 'ditches_buf' included in my
> sample dataset?
>
> For me it's obvious that the output is plain wrong.
attached is a screenshot of the original vector in "aqua" on top of the
1 and 4 meter buffers I've just created.
looking at "v.info -h" I see that I did load it into v.digit to have a
look at the topology. I've tried again with a fresh copy of the mapset,
same (good) results. I don't know why it would be different- but for me
that works.
But it doesn't matter -- I was looking for a simple example of it going
wrong and I think I've found one:
Can you try buffering this simple polygon and see if it works correctly
for you? (I used a 10m buffer) If we can fix the bug causing that,
maybe your area filling bug will go away too.
("v.in.ascii -n format=standard")
B 26
600039.02641686 5678405.3999173
600077.97320276 5678399.62882899
600086.74267773 5678396.53372018
600165.15210099 5678369.45151806
600169.2571522 5678367.86458082
600321.12416744 5678313.92598028
600329.91897615 5678321.23595115
600333.66876785 5678318.50222813
600324.59956919 5678312.02422909
600321.23100969 5678310.98774925
600167.57287245 5678364.49602132
600085.45304905 5678392.66483416
600077.19942555 5678396.27579444
600036.44715953 5678401.36982765
600030.38590477 5678402.27256772
600010.78354895 5678405.62560227
599996.21074494 5678408.39830396
599987.18334424 5678410.71963557
599979.96142368 5678412.00926424
599968.01258083 5678413.77867984
599954.94262744 5678414.84644733
599949.52618701 5678419.48911054
599968.61269136 5678418.4574076
599998.40311369 5678411.75133851
600001.62800241 5678411.19452149
600039.02641686 5678405.3999173
C 1 1
600232.43677669 5678342.9534263
1 1188
Hamish
--Multipart=_Tue__12_Sep_2006_15_29_18_+1200_6VmhFaX/IeDFNAvu
Content-Type: image/png;
name="ditches014.png"
Content-Disposition: attachment;
filename="ditches014.png"
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAkkAAAKYAgMAAAAajIQtAAAADFBMVEUAAADIyMj///9kgP/JvWUj
AAAc5ElEQVR4nO3dy2ojS5oA4FS5RINpcBk7mc3A7LWaQ20LJLdtpjEFlk5lDrOeV+gXUC20mNnN
YvbWUAtNPoULXLuC4ryJTPVSgyZumRn3+P+MvB2OoqHhqCTl54zI/49bppLCVtLV40v+YP0no2yy
x9c0q/5zm6/mL3k+g33YVtZJ26ZdTv8b+mG4aZffzy+hf2pKz8uv0n/nV4d7+YURmDb53fEyz9wf
GMQU2aDspm1+fbgH/qU7dloe5A+PzxTdyONNW9akZ9IrsY3cZfrHCFNsI7ebNtmn1xT4h5qm2AYV
b9JCZhHfoFymv0WYYhuU3RSRWrgpqkHFm/SQWfBGfj0yU2Qjt5owqWXHjv+gvRbVyFswaWGclrhG
3o0pLmpaTXGppYhtUN2Y4hpUV6aYBuUwXYFNlpBZ0EZ+fVg1bVBWU1y6Y6/GRM12TMZ7oxq5wwRP
wZYwXkQ2cqspMrWwlyMaeaxply9JwzHfGxM17abLx7dgkyWMF3ENymYiqeVDVGphpuYNym66eQ81
WUMm+w5y7TZsUHbT3UWsiTXyVXsmklo+RKUWWiIaucP0PS61FFGN3G56t482RURNu+kMnIJTa2ph
/9I4atpMm+wqMrWwb2ncoOwmeAr2mZo2KLvJVR9GcaWWgjXyhg3KZkKlO3sYL2KiZnem5lHTbvoB
NW3ZcWfWf2vcyC0mzOjOGcaLiKjZhslxKkiD+vjquAC6NDnDeMEHVB9uGjQoiwkzuvOZ6DTUj0mD
BhVpcqeWgjby+/dvGzSoWJMzjLMvWn381iBqWkyb/Oq1FRNp5Le/3Ldjgqe7HRvuOg+a5mffG0TN
eJMrjNNvyt/+bBA1rSZECqammeuft9nqQ4OoaTEh0p0vtRSNB1TxJldqKRpPQ1lNxkSuq2wCE1Vp
ft0gDZumtlIL+3fyXdfoBtWtifY18VHTZvoXsCnN5t98lygbUKGjpmlqLbWwNzTpa3ZsatTXjDIF
UkvRcEBlmhApOJBaioZR02LCpruZ9x3ZJ3TUjDIFUgstTSbvbSZwCg6kFvZtDaKmaUKku1BqKaqo
2aMpEMaLZlHTZoKn4LCpSdQ0TJh0F0ot3ISOmnGmUBgvGkVNiykUczTTg/89DaahDFOrqaVoNA0V
a/KnFlrwUdNiAm992oKqmUfNfw29zWdCpGBAain4NBQuapomXLoLpJaiSdSMMQFSSyEGVKioaTGB
UzAkjBcNoqZhwqa7MJ82clTUjDFBUkvRIGpaTOAUDEktRYOoqZsQ6c62G8tasFEzygRILbTwqBlj
AqdgWGopeNcAEzV1E8kX7aaWQgyoEFHTNIFTMCy1FPhpKNOESMHQXVLIaSjdhEjBm/wC+FZk1DRM
iHQHSy0Fehoq1gR6KzJqmiZwCgamFvZWFjX/raEJk+5gqYWbMNvrmpvAqaXARk3TBD0QOLUU2Kip
mZDpDpRaCuw0VHMTOLXQgoqahgl8IHBqoQU1DaWZUCkYvgEXFzUNEzgFw1NLUUXNf29mAv/x8NTC
TCxqwhq5ZkKkYO+SufluRNTUTfB0h0gtBS5qGibw7mNEainEgAoYNQ0TPNfDU0uBi5qaCZPu4KmF
fTN8QBVlAofxAhU1DRO0QlCppaii5n+iTah0h0gt7P0saj50bQKH8QI1DaWbwBWCSi20kKh5gEVN
1YRIwajUwj6Q33+ARU3dBE7BuNTCvnt1C5uG0k3gRoJLLQUmaqomTApGhXH2CWjU1EzgFIxMLezL
oVFTN8HTHS61MBNwyVM1kYYLbCTY1FIgBlSaCZzutvktKowXiKipm6C7j7GphX07sK+pm6ANF7au
oX8GNg2lmBDpDp1aCvjkfWMTba9IE3QaSjOBLyZ0amEfgkVNxYRIwekKmVq4CTR5r5ngKRgdxgvw
gEozQS+mBqmlAEdNxQRPwQ1SSwGOmqoJkYLRqYUW2DSUZoJeTA1SCzsAKGoqJngKbpJaCmjUVE3g
FNwktRTQqKmZyJldJDOICZ9aCug0lGnKiepN0EQv6ga3QoG6BrKJpztasiTAapRaCmDUtJs4K7E+
54SbmqSWAhg1VRMNOnKhrnOHCR/GC+CSp2xiKTjXy9LiapZaaIFETdVEUjBp4QaLuhRWs9RCCyRq
qiZ6XlNSY5MACzv5JB8jHDVlE0vBS3qeMhdrVn5zo9RSVFETbqIp+H5+ZCB23RmsBWex1NLoXnJI
10A1Pb5evzuSchDnibqmJqtpaqEFEDVlE03Bl49HXg7leaLXXaqyiLNRaqEFEDUVE0nB0/lRKuV5
WuishqmlAO28V03zl+VRL3t+nlQW/d6lO8x7CmAaSjN9ezRMtDwLVnUxsvOfO4K8v4SjpmSi6S6d
W00lKytPFu9AsMaGNfGoCTaRK8JFEqzyZNE738sGD+lvSYXOa37zBlzNdOYzsUY/ZSfrrjaB+luK
Kfvoj5qSiabgOW/THtWenay3agciQ5wsdivzpa+RK6brAznoNx4rnQ2LnaxPh6UW5RfglkWi5ndv
I5dM0/zqJ4mV1zxWLnwuHh/0IB/qnIpCouZ7b9egNtFzenE8vq74eUqFy9PiJ+y60+rwPGhiDcoX
NWsTeSsNmN+mVV0wl4d1YO/QQvwy2LRI1Lz64IuatYlcULe06tQ2kjDWhY30k/yPnayF1rEJNa00
u/7ha+SViVTdzaOoOrWRJOyPt5ym44/yZGV6PvQ2rc3q7qcvalamz2Q4OK+rTj0AqyLjbM3nUsta
aNehp2mFdt5XJvLHfuJVp1cFq41pPv+mn63vRstSP+hqWqEBVWmiVSeuulmxM7uYy8lcBK76bP1U
L0PeZ1bPs7VphQZUpYlWHb3q7vMlf0Hv+pKsy19ZVqzvR7UkIjpoTctsWYGd96WJV93xWokbsov3
BHiYFJVYticlOkyNppXN9IMG7lcSpidedfuV8c6y51v2TihoSnFn/LrTy95sWg/6QQMDKmHa6FWn
vmcimXIRvUnbeW8xldeh1LSMhiP6mgFTmi9vjaqTviRJZVMuTsTCFeMPZRWn9spL86ujO2pyE6k6
Mq6zVV31LZopF3HSmXr2ZS/eVnn+RzRyE6m6d7zqnM9KoT1LfSphIVKPoyf4zP95ap4Q/4CKm0jV
0cFBmuZ/8ZkeqhYv1SFvWo6zRat4ZVaef0DFTKLqDkv39Ul6uxP+HWuTNcmtuUc0rWuz8vxRk5lE
1X11V12RLqRNq2stiWRVNLWdrm+WyvNGTWaqq84Z79O7g7yRdmfMI4hOp4W1t1SeN2pSE6m6O1F1
527Te21z75OZEx3dLUvliajpNpGquwpUHTH9MDccW2apbN2tb+b5pzflOaMmNQGqjoz99PPEX7ey
purJ2t+YleeLmsRUVl3mqTpiOjjGrmbTIueJdRDOPJXni5rrpKq6G0/V7fKFZwLzyThbmegRz12V
52vkxEQ+HKo6Nm6f+Mb4O2NGb8Ez4pm98nxRc52QqluIqrO+ozIFJ3qfEmO0R//PWnm+qLlO/iPP
L8nHXi0NEWmiRWPRk3dhrTxP1FwnouqmvqpDrbWquWc5If3X/b3xB3umodY0nASrDrn+q+SejA7R
3hnfTgdUjqhJTTfBqkOvSe+kKrx/tFWeJ2oSU/anYNU1WSevqnC55JWn/bs7ahLTKlx1LGaiFzPK
KqSTpJdGQHY3cmJaHMuxps90C7i13PwYq8Ib0tV/MerBHTWJ6U+8j2MZsESbSKHXdWarPHfUXCfs
qrNkJM0EuQXfWsgIezo//t+lfkrcUXOdQKouxkSOvSJXHqkmra/PG5TVJKou9OiWxgtRdLKNhM1X
4xC0a2CNmuvkn3jVuQYsvGB3i6ufpWPsg1F5zqi5TiBVF2Xa/Xd+T3Lend5knVGTmTxjzRZMpPJW
vPK0tuN6ejM1Ha7dY802TOSqp5VnDF9cjZyawlUXZ9rxIe1bvfJ41DTTLDWFqw5p0qcxUxYNftMr
zxU1qenan3/RJtJ5V1/Y8PlbfWumK2oSE53hOW/TtNWbwv/wGbdr/Ti0kVsaFDEBqg5n2hhXfcoa
lDFxQKLmT8uAipi8A5YmptSYLtywBrXXK49EzfeWaah1svdNE0gm+IYCYjL7AJ945SnHdzw2Z51A
qo6ZoHfY7PKl/tZdtXDyoL18ZYnkZNwCqDqk6caoj5T1ykkgXGov31k2r5D+U6DrJEwX4P1zpJ9s
/O0bll4OeuXZn3KyTsyhl82E2NNHTJd6r3XLOpu0E/Wgvmy7vYSOOQHHQpqMfvaOjxRetYOx3VAW
E6TqsCbzOLxBHfTrKaXXsw6gJu3jtoJ4JAUbdxnH+cyGeXQ8fK58r21fKzF5ByzNTOaDDUTlfdUq
b2tr5MSkfboVk7lRMmXLzXrl7VgjN02zXkwbvlVA65WLXy9RCSQ+QY5DTF+hJhJfLSbSWfiHuRkN
Uss2xHWif7gjU7lXQBtw2xr5GrYhJ95ULsxrlccbuW4CHacFk9jAoFUe/7EJtZH3Z9rx2TEtlO8s
2aU/E12u+GRGA0sjh5veQh+gsGUTcKZJbGF4pzYo3sgbm8zDeEwz43VaeRcslMsDXNInn1+qVdCj
iQ7zzMojF96Fll36NG3YGF0L5aSR335VGznUtJrHm5545WnRIM2WX++bmT6A7z9wmmjl/c2IBqQL
9UFt5EBT2oqJV95BXR4gF562k61X09Y2wbLNb96rjbwDE7keHCYyRl/d6pVHhl4f1S5UryZaeZke
DXb59eMvSiPv17Rlc+VaNEj1jUdg0/s2TDs+O/aiTIQZXah+TaIHvFe2fhmD4Z5N22qVaia9Rjce
dW5yroOIHrASynf8MUz1B7oyueZgpqzy1GigN/K+TXz4okaDVGvkYBP4V0T9JlF5yhid7xMZziSG
L8oYnY5d5Ebeu4kPX5TK22mboXo3ieGLHA30e/J6N4nhixIN+O86IE072pEHPwNyNfeZ+PBFGaOT
7CI38v5NfPiijNG1Rt6/SQxf5MrTdvwNYOI9YDmUi/WEAU18+KJEA5pd6kY+gEkMX+RQrjZysAnx
7FW6RO8z8cqTQ7m6Qasrk2++gw9f5MpTu1BDmEQPWNp+pHahhjCJHvCLtPSoNPJBTLwHLO9g4TfD
/jqgaccm8OVQrnShwCbEcnDQJBb3pe1HSnYZxrQt83BWvSA18vZNtJ5DJr5bRKo8dhdO2ciHMdGt
PrdKHk6liVmYCfEALZiJr8VKeVjOLlATfMsDyLRjkxnS7NhGauQDmcRWn3p2jDfyYU2f+ca/qvLE
RrbZkKYd3/hX52GeXTo0AcbxKZuXrqNByhr5AzdBntXQgYnvzHipFjp4F0qY8mV4WbEDE9/4V28D
pl2o6jzlgE0PHZjEPq2q8kgX6uNSMrW6JQtoEvu0qlBOLrzVtGzjubGDqh8Tfw5APR5O8/L32Ycz
iVBeVd4mL29EWrPbd2YAU+zSq1GmrPKqbcDb6uTQ685701F5HPA2DLBpq05tbquGvU4W01XwGzox
icorowG5EMU4Zp087sOrhZ2YRB6uxsOfy9ZOTIBv2HRi4kOqajy8S89RJsS2Hrhpq1ZesS6GN9Xj
4Znyejcm8EOCs1tz+xEzhX9BpyMTffrL3Nh+JEyhb+jIRDuXP8w7OgY10aeq/TQrb53MhzXtzZ2k
Q5vmr3N9w8HQptX89da4o6N9k2/p1WYiPeDf1Mob3jTVlxhHYLo0QjkxAW6sI8dpZdlcK/Rxpd+u
lSFVZQr2ars0pdf6nZXr5Di0iYyH1TsrYaa0S5O+SgU1wX/RkJmmsDEOf/xtdq3dnAc1wR+dG1h6
NU1iarMO5WMwKUOq4U1L2pL03SIDm+iQmS10yKGcmAA3HXVqumcbDqQlRmYKZo1OTTdsdkxaYmzf
FFx61U1/ZdHg7/fSOueApi1/FPZUnR0bhem/+EJHtfFvDKZd+YSDar5gcNOsSGk0qPMwwjTrxETT
9YZFgyqUg03tbXkwTVu2/agK5d2YgP3k0sRvQT3U85nH8C9a0lzZ4hK1ZLrlXa0pq7y3IpQz00PQ
BP7tIqRJDAW3LJSXQyqgqdWlfNO0U/Zwj8PEo0F5O85ITDwaiNtxBjVtql+m2bJbUEUebt0EW+bU
TfwWVBHKR2IS0YAPqYY38Ti5lZ53MrhJpCERDdiQaiwmEQ1YHh6NacMeXcVCOTGFp8c7M0nDiW0d
ypkpdDS86QFtEjek01AON7W89KqbRDSgoRxkwm41amTi0YCG8vGYaDTgQ6pkSFOq/FAkiQb8XqoF
zAT+TcMIE4kG/HGNQFP72wtME48GJA+3boIvcwpTFcpENLgb3iSF16m4SX5MJh4NDjeLBLCM0JNp
x5//+ZaaWt1CgzJp3WT+YJjfkjGZ+H62v4/qPIknDXV0nmaNTCIaPHdh+trQJB5W04kJtQQkm/ju
Vripiy0PuonvbgWZNn2Z+O5WqKmbrSHU9KAeiUSDoU1a2GC7W2Em8O8Ko5c5NRO7UeE5ARyto6V8
vlSmmNgeu2FNZveP3vkyNtMTiQZjM9FQnozNRCpvMTbTlo7vujBhlhQf9BfzTs4TcMvD1vrrumkn
JuTynf4FIzDNjFeHNpmXw46M78LLUvQ4+95MxYaaHkIfTrML6NQbznRrM22BpsevUBNqmdPardkB
TbfgJ3fFm4oEZFp97GbZ3G5aw0y9nieg6WKE52n+PDrTspNtGNJSWQMTdmsIeqnsj2lqsCylmgCd
QqSpyVLZaEyO1HgyDWNqusyJNfG5htC72jSFf6JprCbotGmfpi6WzdWlMqwJvk0MbbK8FWbqZnuB
2xTuWHS1vSB1DBvHaQpPOGBN+4ZLQLWp/fPUdFnqZDqZ9LIdpan50ivG5JgnijVZlspKUzg+bRFb
stAmy1vXSTg5/cFM1rdCTcAp7x5N8C1ZiO0FzlAGM3Wy5aFXE7Dv7jGFp8c72/JwMp1M7ZnsS2Xc
ZHm1R5PlrW2bEMvBYzVZ3woxueYdo02Oav5dm9rfXtCvKW655fdryj6BnwTXo6mbbRhRpo62F7hN
llf/sCbXUtnJZJqsbx3S5Hpr66bVfD82U7qcfwebbg/WUNa6aTX/ADZ9bH6eXPPYdtOfEe3pn3sy
vQcv5WeP9moGmx6gpj8jTK7zFD7ROBNpT1CTsz21bCLXHXhJkVx3treCTCvUeYpdKoOaoMs6PZo6
2V7gvJyHNLneejKdTNV7EcvmPZlQS/luU/gLRmhyrkE4TbD3jtZke+twJudSWRcmYG5swTRr33Tv
+FM7MIGX71xv/d2a7kdp6mAbRqSpk60hPlPwC06mLkyIpfyxmmxf27IJsZTvXCr7vZrwW42ApmvH
1w5pcq3SdmACbsPo1RS7fAc2dbFsfjLFmhbhD1/3bcpDP+tGTZita22Y8sWb0Ie72Rpy5Tj9/PfK
zocx2ZfKuCn3timUKfsENTmX74Qp9/2qIs4EXjanq/H2r10nkxCqM5NrpW+dZKEzhd7WE2+a5Enq
RQ1gOkzyxZShZo4PI03AWOYzHQ9JumSohR2FNEUvB1PT8fg89aGGMR33PtRAJi+qS5N1YkCYfCjk
9qf2TDXqfDymCrXUUSwJtG+iK5Uu01kI1ZnJtTJDcksIhdq6tmrFNAmhcNtVXI0EZcpsKLnnidxC
04Ypt6EyCTWEKYQaxBRAIbf1QK+HgMmPGsA0DaFw23pwy8EPdtOTG5UMZSoq1IWO4v3hIUzFE+uP
Z9OlHdWNia6Y2JfvmKlYM9TSgerK5JzdZyYf6g12S1ZbJg8qezOUyYfqZksWwFSiUkv1YUz3roup
iUmgFulyrqOGMxXrnKMWOmo1h29dQ2wvgJiKxIHCbutp0+RC4Uzg7QWupTLVZEOlS7at5y+2D1sP
1LapROU16jldXBJT5p+HVQ7UskmgEhmV38xfchgKYaIz3PblO8NUo0rTcZJTEwiFMjlniA1TIeY3
82qAfJgwEwTVlWlnos5ejMFMv6YSNZHPlDnC6tckUFkDVHcmG8oyFu3XZEHtUwjKE3SiTRbUMwS1
I0GnM1OxmzZBYU32WSGXqRphWVDnHhNuewHS5EEZs4u9mZqgdvAtD3T2z7585zM1QKFMzllGnwmP
Qiy9NjWhUX2Y7KjUiWrHlPhNJSqRUQsnqh+TQNGuS9nzfM6dqFZMu6CpRlXd4cSJase0CJowqN5M
CJQnOFtN1tmOJ4gJjmrFtAWZwCi2NQRocq7MAE12VG6gcCbH8t1noKlCpRKKDwWXM9kE3vLgnj3b
QE3FEx/NLEyUtIS8hW95aMNUDrG8qL5NEurChdq2sfQ6RZhq1NKFasWUYkxhVCtL1DiTFSVeas20
Q5oqVD2PnmTSRjOs6cF2iBxpKlHS5P5EQg1jMlEHCdWG6Qlv8qLcidU0uWb3tw1MpB9ookTmwZhc
M+mNTOWcp4wSKzNTsMk9K/Q5D/d9USjw1hC3adPQ5ES1Ycoa1Z0dRft44O0FbtO0scmCoh3PFkxp
c5MdRYPOMtK0am6qUfMaRU153CpIumrYxhXUokZdUpN/i7xsmtn+IcpUotIadUNNnok8iOnuOcZk
rPcdJswEQHVnMlEXr4Epz+rQjhnibbTJQO1/Cc3DlibHbOw2v4011SjRnQpPDotDO2Y7yD9Em6rl
2qRGpWGU0/S5DVO1Mlqj3BN5YdMmv2jBZKJsUwlgU/bYhslAVVMJ7ojuNE1bMlVryGcayr1e5DSl
2bwdU7lcm4FRbtOqJVO13gdGuWb0du2Z0CiniXR3onJwBMo1o0fzYGsmKyp1ojymQ0SfzoGaZvX8
Bg+emeUYrlnGbbsmgZKmEhIR0S33h7lG8fSGsTZNYmFbQj07UR7Ta3vtiZYnMMpl2rRugqOcpuxx
32rd1ah6R6UD5TG9tG0SKGnGmqDErMsMYEq7MNlQYoJDvj/MbZp/bd9kQU1NlGumiqS7yw5MJqra
OVzfG+0wsZ+168IkNu5LOyrVmwmYyT4rtMuXR9Q6Arzw/czS5kUD5TTddWWqUPLdfcoN244bhp5I
urvvyGRDyZP7rmUEMuI8YNcRYlDllPUbr+mqQ5NAKZsXOYr1pxwmMuJ87dDEUYRxZkM5TGTE2amp
RNU3PR2mFcplIim42Zw9GKX1hmlDL29QcZpeujUV7hvpHKa0e5NATU1Ubl+WSumvuHZs4qjlVLln
LfWaLjs3lSj5Vh7WybMulfFflu3c5EI5TCQFN10DikXl9md/0hHnfR8mgVLuxErYVLRxgwodcd5n
gX2H7ZQJ7+MpKGoyRu0sBfdj2pWoeY16e7TcoEJHnD2ZKpR0fxEz6Sg64kx/7cdkQ9luUCEpeJ/3
ZSpR8v1FL6mBYumuN5NAyTc9TcRM0Hn9JpbuHnoz1ai6O2XM7dMRZ5+mCpUYqFlloqmlT5OYnpJR
PPXVQ1FmmvVpEgNk+a4ZgRIInu76NXGUeiuPjOLprmeTiXpOF/WobxhThTqrUfWzw3i6C+397wxV
94af8wrFRpwDmARK6qKX2wQTkYIHMHHUUkJV+8x4Ch7CxKenJFQ5FM2nLAUPYuIDZAlVDkVzloKH
MVlQYihKU/BAJhuKTS7QFDyUyYLiW7ouBzSZqJRt6aJrxIOZDBTNMjQFvxnQZEElNN1lbwY08ekp
BfWWmPKsj3GwsyQ6iqQ72sUb0mSifpkMbjJRNMsMbDJQdNv+0CYDRToJg5t0FOkkDHrdWVH7rtal
olAjOE8Gqq29RnFFRY3DpKJGYvrfiYQaianaE0RRYzHJqNGYJNR4TDVqFPFJlBI1hjheFYEa03mq
ZqxHZSq+jKCfaZQvI+hnGuXLCPqZRvkygn6mUb6M67rjZchxsKucTLByMsHKyQQrJxOsnEywcjLB
yskEKycTrJxMsHIywcrJBCsnE6ycTLByMsHKyQQrJxOsnEywcjLByskEK6M0/T9umX2N3nTYVQAA
AABJRU5ErkJggg==
--Multipart=_Tue__12_Sep_2006_15_29_18_+1200_6VmhFaX/IeDFNAvu--
|
|
Tue, Sep 12 2006
10:36:45
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<45067199.60007@o2.pl>
|
Date |
Tue, 12 Sep 2006 10:36:41 +0200
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.5 (X11/20060728)
|
MIME-Version |
1.0
|
To |
hamish_nospam@yahoo.com
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results
|
References |
<20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060912152918.77a48f94.hamish_nospam@yahoo.com>
|
Content-Type |
multipart/mixed; boundary="------------050509020400040608060005"
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
This is a multi-part message in MIME format.
--------------050509020400040608060005
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Hamish wrote:
> Maciek wrote:
>> Are you absolutely sure that the output of following v.buffer
>> commands:
>>
>> v.buffer input=ditches output=ditches_buf1 type=area buffer=1
>> v.buffer input=ditches output=ditches_buf4 type=area buffer=4
>>
>> looks all OK after you zoom to region 'ditches_buf' included in my
>> sample dataset?
>>
>> For me it's obvious that the output is plain wrong.
> attached is a screenshot of the original vector in "aqua" on top of the
> 1 and 4 meter buffers I've just created.
Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
I wonder how such a difference between your and my results is possible.
> But it doesn't matter -- I was looking for a simple example of it going
> wrong and I think I've found one:
> Can you try buffering this simple polygon and see if it works correctly
> for you? (I used a 10m buffer) If we can fix the bug causing that,
> maybe your area filling bug will go away too.
I tried. You can see the result of buffering at 10m on the attached
screendumps:
hamish_area.png - your input area
hamish_area_buf10.png - 10m buffer
hamish_area_both.png - both, overlayed
The 10m buffer is wrong. I'm curious if you obtain *the same* wrong buffer.
Maciek
--------------050509020400040608060005
Content-Type: image/png;
name="buf_bugs.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="buf_bugs.png"
iVBORw0KGgoAAAANSUhEUgAAAaYAAAHDBAMAAACdZqPZAAAAD1BMVEUAAAD/AAAA/wCqqqr/
////JPrCAAAQa0lEQVR42u3dW47rOA4GYKrkBTjoWUCQFQjIBjKA97+mju83XSiKtCR38jAP
Z7qq8oXyL5mWHei8r8/jod/q0XbE1/dH//n+/KM5/Ov315rv/5B/r/cF4qb32fTpOf0/H/79
GlP/nr4fqCL+9u+bV/3Pt6dfK1konKmhm7TNJFuoPKa+ULlMw9hR9L9sjwjpwQcZIkJ68Ima
XBEhXCgIfM5SJslCASYiFHdEyBYKZWKPCNlCZTMJFgowEfE/7tibC5XRxB8RooNP2KTdJrnB
B4jDqSUPveEjcf28WKEgV0QIFkrY9PaZpAoFoWMcyH/x++PgH7pChYJcsbfEueeIEzEprcVi
T+40CvzHAyTUKRQR/V8XGXwBk05YwYYiQiwlAiZjUiIiaJJJCQjkVlLsqeCMLVIoCMZegkmH
VyEShQqbUldGwe4Ae5yDN5S0bOwtcW5YBx8IrmDDESFzGhU2pcQe5iPhn3clTQprYi4UBD/o
JiEiMKYhzrVSfIUCqWYEMiKmQgFnocIm2YhYC8V3REFofmkTIgI5Y/cpYcw1ppQoR0fE9N/2
JzVcgy9oEl0ZycQ5SMYeNsuY510QWsHiY49/dR4yXRAR7PMuCMYePmF4CwX5Y499dR4ySa+M
JE6jQCr2IiKCO87lTO8oE2ecg0iUf+IPD8ZCgVSUq8iEYSwUiER5bETwxjmIRLkijNwlzlth
01WxxxrnIBF7kSsj7nkXJGOvjf0pnpSQMmnC0cgV51BI7HEWCjwRkWBqSVVmKhTIRDkhIvhO
o0Aq9igBxhTnQiZFqzJPnINA7BEjgq1QIBV7tE+EJSVkTPErI844B/7Yo62MGAsFfGsblp/m
KBSIxJ6mm1R6SkBJsccU51KmlPVvaqGAPfaSIoKlUOBZr6VFRMJVnsSUAIkoVyn7KtLjHNhj
Ly0iOAolZEraGTD/BuqvAIHYI6+MmI5I4P6kU2OPIc5BJMpN2iI0Mc6BO/aSIyK9UMD9SSuO
s7q0OIfyYi85zoE59hgiIrlQIBF7/cBNM31SLnIAf+yp1IiY34RRjKaEFSxH7M2DTxPjHGxn
mgyx1ySaUuIc2NsJqSuj9JQA3ihnir20OAeBKDcsuxzohQLeI4IrIpIKBbxRrhi3DZFPo0Bg
Bcu0VZw87wJ77L0ZTbSiA3/sGa59rdTTKLDGHtAjAvhM1JSAUmMvIc4FTHx3kxALBZxRzhoR
9EKB6ygHKMBEK5TL1N+/M72aOJPhvI2ONO96TPOrRcuYI6IjbuoD1wdzfI0y1COeGE2keRdt
ml6+4bi8gabjLVTk4Is1+YrGHhHElAD7CrZ/14/g61A0/oigFQocEaHf7zn3FFamJEyEQjlM
8F5fBoUb/3/NbiIUCiwrWNMfFpYXAscdEaTTKLBGhH57XwPOmh1DRMRO1cg4R39WVlP7Rrxs
ru103Qans9h5FxJMoN/I11gRu2nJj+bqlADL2NXL242RDc/AOZqWgjWJhYq5Id5mGg6ZzdQa
UTTndN0mHGOfyBvi4fSJDGUy6jQBAWZIgis9tjJiodApsfsD/bsZ37nyrIh07FFmn6Qj4zyi
UHCo8RjjJrjY88HMMHxRJWuwhVIRhYJ9icfZ1gQXsdNbcqC03pZMPZIHY9xpFOxHXruOPP/H
POarYzCa8wytwitGTJyjCrX+po/ajbz+E/l4jwxtXMeZ1o51VWgtzLPoA8fI215jBrDatHEc
Z+ZQqIj0YJl3l9/S7kee7fM42LShBMgssw/GhqNQ4B557p+ZFg3Gf+Tr8Dr4vGDkKBQcR977
OPICB20o03TcVAYMhYJj5gEqXWZTG8w0tEz5R1/EvVGwkLAjb296fV9PCB37mMPMjKzW8xeR
hYLlYFpHHu6ZRMPzBgfT9Homw4xv9C2Dr0WZ1H7kAW4FNmydeR1eOJhL5hv4+HkXKCNvNGmb
aQNTBJmvDuiUAMrI89QpUeYbfeg4B8rIm46ngIkk832q2ELBduQp9CnKZ/r1YdNGFsz8wOjH
FgooI2/9yP5eEa8gDPxjBRvn49+ICwiqKRyM2v/JIuddeDiX4zKm8eWYpPvD2vPRIuMcwstx
CZNL1gYLhZh3gTLyuEwWGTAUCigjj9e0yOZDyhMTqDiHqUzqEdGQljD1rPDoQ8U5jJea4kae
kOk1Z7Dn3WAKBdFTk6DpORfKvZbFxDlELopETS/YTlItdd4ljbz18jyz6TUvaoy/UNr7foEy
8uRMz7lQ4CtUIM6XJVbchWUp01Ko4XMG2ry7zHFNtKn/OXbTc+7JOUsRLhRQRp6gaYiJ9u0b
fcGrUUAZeYupffG/luapChXK9aaBMvJETc95Ve1628E4B8rIEzWtMdGPIEWYd0kjj8P0DOf5
0BxoHIUKmZocpr9woVzvO5ASELkosrSWiSbzhyrUo4lOCSBt4+IwvY2/UDpQKHdKQNKjlZJM
77/g+twVE8Pf95go+5yETS8ViIm+gefeMAH0JyuBnGktlOONewcfbQuQtGksFLhjwpsStB12
Q2s5zaS9pucy+gKFqsgUjAnwTFGlmkIx4Rt8xZqegUnKs1GRbjJpp7naM+ceRp91iC0bFWsy
vfwxMUxR9vPGgk2BmFDTezgXqmDT2u2zxsTwzT3WQpVsCqxlnVNU0SZ/TIDrUSB0k5Y3+WPC
OUWVbXruehMNciFbtmkcfeCIiaVQdZm8o2+YoiwpQTOpy0xP5YkJx+DLZfqePhncf+grlD0l
yCZ4X2NaJylwF6o2026SOsSEfYrKaML+MLhHn/026wpML09MWFOCbhJshbkmKUehTIWmdZI6
dcKtUxTZpC80eSYp27N1qjB5JinbFFWHaZ2kTpfjLVNUJaanczOIZYqqxOTeDGKZomoxuSep
c0pUY9rHROOboqoxvWAbE61viqrH5Nwzdhp8JBPDZUIdb3LFxJISkN1kon/GFRPHKYpqGh8m
c61pmKTgHBPzFLWYKA8KyGRaR98+JsZhsz6LbtwJ29BMfxebXDHRj7vt2HsQNhx90nf40kyO
mPjsb+6ty7SfpJrtFLXN8rpMu9G3xoTaIaAl7AzLaLLHxGdngPYNqiLTcia1jwm1PasCytPl
cpp29z+shdo+BqU60/7+B/u+sOpMw+gDfT7pqNn0HDZweW5UAcq3YeQ1vYYbK7T7VgEA2hcS
t9e1lu0mcN8qAClfHJ3TpMAZE3Wa+hD4xxkTVJPOblrupmxvZHq4YiLFdG2LZZvlo6l1xATZ
dHnbaG8yntVE1abWHhPjvXeVmhwxMd57B5Wahpg4jT6gPMi6HFNru85Wsal1xUTNJntvom7T
x3F3fDYT/VTjuTxSfO6MHWIik0mzmDpljQmgneYWYvpYY6JC0/w4e+gOhWoqN01v2hoTQG2x
lGFaC7UZfUD4Iqxsl2ospo8679oht1gKMY03iu9jIk/biNFkiYn6TeeYqN90jokbmD7HzX1V
mg49/uO+iTuY9nne5DP98Zn2ed5WaJrbe+1+d84mJuq7rPG0fMvUPibuYdrHBBC+p06VZ9oV
CminuaWZOtgU6i6mbslzRTXp4kyf9f7kBFPuVtj5XU2jr0qT9VrMGhNQY8vSfn1pvT/5PqZl
2Xcj0xIT9Zm27T376IPq2uWe7/GeYuJWpqlQ9zKNMQHmcSPT+C1WYHI8SFVLmYbRB6TTp3JN
nxualtuhKzN5t7t+Y+J2pv5plvTLGlCm6f8KartU8wyZug/R1D+oK5PJ0t47jj6ayajspo7b
pPOa/G+aejxB1tZywKRqbJeHTc3P9DP9V0wyLZaspicUZ0q+BKBaYdPjctPz0TK0wsoyKRYT
lGR6qrbvK6aaGm4TJFzWeA7PgEgzKQFTyqWa8QToXqaXuqBOV7f3+uPJtPcyQb+4+buXqZ+f
5FoseUyv/j7nu5kSLwH8TBVc1lhuZL2hqb2jqeM05b0EgDh1v6up+ZnubPq7lyn98pNki+Vn
KqMN+zNVYFI3NsENTU1hJo5dln5T7LK8AJP6mUq/W+Nnus4Eb51gasusk0mpU2uMlCmlFabT
WmG6RJNJMsnUKfFOIaBfqXk+pI6n5LufRNt7RFO21jKmvfc1NT9TAabQlsOfqYx2+f1M+mf6
r5qyt8tvZ1Llmv5+prj2XgeEFkv6pRrRVtjPlP9SDabF8jMV0i6/nQnxHSc/UwHtcowJbmhq
ajJhdrrd1BSLUiWY/N+DBI82jsVhkm2Fjd/l10YkRS2m/jkSUI0peEfxbEKrGC5riJtWFE5V
g+kdqcpt0hjT20Spcl+qwZniVLWY+ue7YVW5LwFEmNCqrCYVadqpWufaQhXfstyZUKoiTBCY
n1ScqghT04XWsFGqKkzDEhavUiW0lhvMeu+kUg5VAe1yhTSdVMahqsK0vneUKrcJ8xXGEKmq
w7Q733CrpjP83Jc1sKYYVT0mvCqrCdcK68B2xus7rnJeqok2HVR6r9os2vObWrwJqcp3WQPX
CuvA3XNpHaoC2rBxJr9KLSaoyuRXzaYH/GUyhR+CCKGu30EFajKRUeLtiM51xrjG90FlYDJ9
//2vLlP3capAq+Xf/6oyeVS7OfivKhNWBZeZgMF0VIFV9YhTibf3umDTf6t6cKgKMLGrntLt
vQ51IY1V9ZRuhXXIS56MqmJMHtX+2kFVJjZVqil4SviJ2m7EokpqLWNOcz+RW6jcKoVViZtU
7LYwp8pgVeJto3hTsqpIU6JKum30eZBMSapiTQmqgk1u1a4XeFZJt/dUiomokm7vJZpIquJN
BFUFpmiVsOnz4DBFqpJM4dNcLpNTZSyqakwRKmGTYjShVe+aTEiVcNuI24RRfU0gaBq+n7Dr
rlX1F1sA6jKFVOMFJNIlEUx7r79FRsB0VOmdajD1f1imbaSkTM6rB1/VZHoQBiDSpIVMHpU2
tGsHBZh8tSJeERnaEX7TsM1G0OS+fkVUIVos43fydd11KutGTryqEFOvcrVuo1UIk7rEdLwd
KUGFM+krTG6ViVJh2kbXmXhUCNO4u/Ai024TCVGFM/Vr5KtMrgUTXoVo7403RF9nwm238KgQ
LZbrTYkqhEllMCWpcKbvcvJq034SjlIN7YgyTftg3y6Y9qq/+BbLtFE8h8k9XXm3nKFM/ebC
PCaSqngTQRU2qdwm99LCoVIYk85sci8tdg3BWYUzmUdek2/X7fukCprm+2Mym2JUwfbe/Ciz
7Ca8Ktg2mh/pU4DpOAm7VEGTKsnkWVrsd2cFTbogk2e62iR7oL033w5djAmj8p/mLrekFmTy
TMLjDT2TCQKx1xRlcm95HMNiND0cT4GYY68wU0A1mdxPgSjT5FswvUFPtylZH64yP/2mK8/k
m4SNXk8aG1fsFWnCnd+f4q1wk2dpseuyW2OvWBNS1Vhir2CTZ8G0qvZPtqjA5FlaWFSqEpNn
abFV7SOieJNnEl5VQ1hUZPKr1n9eVrBVmHxLi41qifI6TJ5JeHvKOEVELSbPdGWgWpN3Ep7P
7MeLHhWZfKphAI4nuU1dJrdqGIDj7iyAykxu1XYXXW2mbwS6VPPJVX0mt2o+uarRdFCdbiir
0+RX1Wryqeo1uVU1m1yquk12Ve0mm6p+01l1B9NJ1XW3U93FtFXdx7Sq7mSaVfcyjaq7mXrV
v0wYD3W8hOidAAAAAElFTkSuQmCC
--------------050509020400040608060005
Content-Type: image/png;
name="hamish_area.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="hamish_area.png"
iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAgMAAABIvzR3AAAACVBMVEUAAADIyMj///8U+jb4
AAAFQ0lEQVR42u3dO47bSBSFYZKAEkbjQJvQKoQGnEwkA+J+OEEDg14F7YjQKk1VU5RstMRH
3Vt1gl9RAx3oA2/x1IPFUnER/xQAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgwBfArqi1gX1zKopCucT7ZvgU
etdxAr434XOqVYFdMwor1bt4PwrPlShwrPEgLDSBXXkTNoUk8NIXxa3MxUG0J2lvxONBEzgQ
x0Ifa1HgUOi9VCB+cT+MF1EkEL+6YceLeJa4Vb5OlHb32RArVeCl2zUiF/FZJt9i+1iIAoeG
eAvtWhM4/Gs3jm8KUeC9dy4qTeAU2jlvlpnyjXmTMXHm2tdU5nOmm2X2Bpju5kw3y4IvnUaJ
WW6WJVdlaog5bpZFZXuYDSTvWZZ9X1/smkx1XnpBuiJTnZdX7IGYss5rvuqBmC4U112LOzHZ
hGBtsbqpe640gfe587kWBU7ENBPTbffjJ/F0kAWO3d9RGPi54FkJAy/X/vl8EAb2aYoc0Wml
KXJMr1qmSMMYYCiyd9ZEjUu6vX8zjBs4tddmWAsDQzP0LXIksHcvcuzYuPXOmujBu3fWRAO9
syZ++hOy5k0YGJqhX5EtJpCuWWMBdB3XmEzBQzOshIGezdBoESM0Q2Vg71Zkq2UgtyKbrVN5
ZY0Z0Ctr7Fb6nLLGcCmydZkoW66Vlh5FtgSGZlgJA0MztM4a2+Xw1j5rjNfr7ZuhMTB0ebUw
0L7I5o9krItsDrTOGvuHWsZZ4/DUzbYZejwWLC0nyh7AazM0K7LLg9VrM7Qqss+T39Yua5we
TZdmm52dgHazPK+H+2azPLfdB1azPDdg6PLehIFWXZ7jBhObLs9zB4zJyMsTaDLyct1D1BlM
5X03ORkU2RdoUGTnbWLxWeO9jy06a9w32sU2Q3dgaIa1MDBkTUSRE+yljCtyAmBc1qTYjRqV
NUm2y7YRz6HS7Octtxc5DTBiKp9oR/T2rEm1ZXtz1qQCbs6aZJveQ9YchIFb12sSvjawLWsS
ArdlTcoXbDZlTdI3gLasDScFbily2neoNqwNJ37Ja33WpH4LbWiG36sPYeDQDH+saobJ39fs
mvP5pAwcivxtTYeSHtjvvq/Jmgyv5Hbf1mRNBmC/KmsyAH+FLq/WBX5c/t8tL3KeMxS65UXO
dMjD8sFrJuDycU2uYzLCuEYZGMY1lTLw2gyXFDkfsF82eM14VMuyDiXnWTKLsiYnMGTNQRgY
suaoDFySNZkPhZrPmszA+azJfaxWO7cakv2wxrkiZwf2M4PX/MddzmSNwHmcr7NG4cDQl81Q
Adi/GrxKHLn6qsgaZ8K+KLIG8EXWiJyq+zxrVI79bZ+thsicS1w+KbIMsH9SZJ2Tnf/Kmg85
4F9Z848e8I+s6ZuDHDBkzW3w+t/tL6nzz9t7kffNWRB4z5q+kbyC96z52Si2wYeseb9VWO7n
P8qwGjJcyTdR4DVrjg8V1vsBlWvWVO/3EbbeT5Jcs2bf/KsLDMuGU4UVgX/OoRR/daZ9HLtK
/spQebpoA/taHKg5ogYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA
gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIMNPn
N0VglJEHaZNsAAAAAElFTkSuQmCC
--------------050509020400040608060005
Content-Type: image/png;
name="hamish_area_buf10.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="hamish_area_buf10.png"
iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAgMAAABIvzR3AAAACVBMVEUAAADIyMj///8U+jb4
AAAFtklEQVR42u3dS27bMBDGccqANt7rDoVOYQTIJis3kO4jL3IPpSvBp6z8SPyiZUqcIWfx
d4G2ixb5wfNx9CIptzf+cQABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB
AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB
AgQIECBAgAABAgQIECBAgAABAgQIECBAgNHA2jpwbRw4fFoHNsaB361zxoHtSHS2gW3buLVV
4Fd7+myccaCxL/ECrNrfz9YZB46jZW0c2G7X1oBD25oUPgW225Ut4Pc9cBzNtW3g2BLXhoBf
HqCFfjMNHPtNbRz4W+Y+03mE87fBh9E8FG2ztglsm4OwG//ymRM4tM8/zfiPysOfVoHjUPlz
/IJrs8B2c/z9IyPwuw34fFoHNhmBXyHA1uUDduMFXYjQZeuD4zhxIcjUxPsfF/A1ulVO4N5V
r8dKSuJjwQKEKYmeRHVVSMdJdd3ni3xXhrScTT7gvg8SrvMB930RANzW+YBhwlVG4OEM+vVA
qTMCx+NKZWKcTBy4usJCkaeOrK+/xATXUdOH/pdfov5IfnFuMrgycwxfnjz1Lm+7Dji7m/4S
tYsccvrZTw6WTX7gi8GyMgCc7Di6vSb4CqNzeWI44xLIFTliOOcabXhKXNkAPu/bijGce5X7
pOXoxXD+Zbh/tGzsAMf/4xIe8pbdyPCMFq0iL7zTMrhURV58K6hM1GsWA/sqTa9ZfjMtUQyX
A4cqSQwjbkd2SQ55MfdLixSHvBjgUCaIYdQd5z5BDONuiXf6h7zIe/b6RY4E6hc59qmHeq+J
fiyj3Wuigdq9Jv7BlnIMBZ686cZQ4tGgagwlgKoxFHm4qhlDmae/O71DngxQschCz8/1iiz1
gF+t14jNQNDqNWJArRjKzeE4x7AZf0nGUHCSyTmG1V/RGErOgjnF8P1dNIaSwFMM/1aiMRSd
R3SMYXMzUN5MAY+HvJtvML7IssBDka8zKFBk4aliY5GvR7FAr5Gey9Y1dyGM7TXik+2kD3ni
QOlDnvx0ReEzL4X5lLJnXhoTPkVjqAH0xdAUcN8LFllnTq9gkXWAgr1GaVa0XK/RmrYt1mvU
5pVLxVANKBVDvZn5QjFUXDogE0PNtQ2FxLRcTaDIA1vV1SESRdZdviLQa3SBAr1GeQFQfK/R
XqEUHUP1JVRlZAzVgZ4iz4qh/iK0Lm6qXIJVckXUQ5QEwLhek2KdYVSvSbIQchfRa5IAh4he
k2YpaUSvSbTWdXmvSbUYt1gaw1TAxTFMtpzZU+StKeDSIqcDLixywhXry3pNyiX1i3pN0jX/
5YIYJgV6ivwyhml3Tejmr0RJvK1DMTuGiYHD7Bim3rvDF8PaEtB38roxBZxb5PQ7yMzsNRm2
uJnXa3JsRzar1+QAzophlg3d+hmLL/PsOFeExzAP0FfkjSWgr9c8uaOUa4vG4F6TbQ/J0F6T
Deh5yuPtNfl24ezCek3GbULDek1GYFivybnRah8Sw6w7wU7E8J8JoO9C+RzDlQ2gr8jHabmX
txhk3uz3WZF3VoDPek1pBujvNUNrBujvNTtDQN+FclNZAg7l5J60Bl4R4CuyKaCv19gC+nqN
LaAnhraAniIbAz4W2RrwocjWgA+9xhzwPob2gHcnrwaBt0U2CLwt8vbnlVGW3nlU+GJoCXjX
az7MAW9jeH6+Y+u1VrvHYWILeF3kD4vA6yLXJoGXXtPsbQJ/e82bVeBPDGurwPNTnmZvFngq
8pth4KHIl7vVFl802ZdXt4JNvju2u3q/Fm/fBQgQIECAAAECBAgQIECAAAECBAgQIECAAAEC
BAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC
BAgQIED9z3+m6dBlJ9QzgAAAAABJRU5ErkJggg==
--------------050509020400040608060005
Content-Type: image/png;
name="hamish_area_both.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="hamish_area_both.png"
iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgAgMAAABIvzR3AAAADFBMVEUAAAAA/wDIyMj///+E
O+5IAAAHqklEQVR42u3du26kSBQG4DLICUnvBJ1PzDOs1C2PJu+VmvdhNbK0cjKv0GsniKdA
ljZxsq+CZlOkXqAp6gBlm0tdTvB3sJqRVppPnMNfVUCBuDL/CQABBBBAAAEEEEAAAQQQQAAB
BBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAA
AQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBA
AAEEEMDNwAN34I45sHrhDsyYA3/lQjAH5jVR8AbmeSZ2XIFv+e2XCuZAZgdRAeO8/10Ec2B9
tuy4AUsRUWB+2TEDVsmpzhiGwr7E+6T+CXIcLyEv4D9J+zspYSYOnIBl0gkDVeZ0xwj4tu+E
54BV3ijgYyKF9FzxXmYFvNxJYUKFssylp3mEUDmdCSHLLOiw0p7NVZBnO8/AdqLQEY9EmDXC
ov7Di09gJSvaFfpIBpas/p+av2YcgLVmPw7E+lT5vT2iBw7A/iDSQMzT9r8/PQJ/5bSk+1vc
DCY4nppQB6wP2P2tEYMhMPMIfBtSLveJ7iAKf8BiONnKZWwfxVAovOVgfZ4IisyEDO3IK3H8
z5EDJu67+c3wIOYi9Am8kq7rR2cxPFkyl8RpwYhQhvbkZHFI1HRUEU/yRpM4rtZ9upYvounZ
XB/E4cmSp/6A13IwU5CzxPHJsvMHvJa0oP0scXSyXA7+gENh34ijkyX0CGxm0JpGHI4s2cEj
sB5X6KRa3CeaOqc+gfXJPDiIQlfn0CtweBApsa+zg3XUx0N/MTxtFVGGov0z+ZO5STWMZ0WU
C4LUM7BZsA9nsv3wHLiJ6xmzu9EYJ9fO58hJkedMP8vRXKYjdgvT1D9wfLJI4il2kDUzJ/DV
eAnaDn9HB1kze4VRjOYyl6bKgf02XLAEGk38m/H5HFtvwyVrtGpAzFSRbbbhskXkILdJkS22
4dJVLo2cOxdpuHwZrs6Wtsgny2245jpBf/3hsldtuGMEVCd02rSh3SKvvNJSCdWGdou8+lLQ
7bhle9tZsxpYxqrINrNm/cW0wE3WrAdWsZOs2XA5siBZ82CtDbdcLyVZ0xXZQhtuAVbRJGvM
t+GmK85lPJnXpKyAgza0tMrbeM0+mrSh6SJvBHZFvrWhlSJvvevRFTkjRQ5ZAa1nzWag7azZ
fmPLctYYuPOmyZqQFXDQhrHpNjQBpG14NH1h08jNVdqGpi9smrn7+6rasMsaY0OeGWBFhjzD
WWPo/jkd8sxmjakb/HTIi0xmjbEnEIJJkc1kjTGgrawx9wyHpawx+JBJ14ZfSdaErIBdGz6Z
bUOTwFsbPsd3aqG8vQ2NPkfUtmHWtqEs8g9WwHbIe47bIc9Ukc0CmyI/Pd3S0FDWGH5UrC5y
/NyloTCSNaafZSvqFjS6yjP+sJ3pVZ5xoOlVnvnHFemQ97C9DS08T1lMp9chK6DZmZcNoG7m
xQp4LfPJzCtkBZRFvhhYytsBGpxeW3oq2tz02tZj28ayxtpz5aayxhrQVBvaezKftmG0vg0t
bh0oVNZ0RV7Thjb3NgSTIq94LNcmsDKRNVZ3h5jIGrvbV2jWrHws1y6QZk2wLmssbwAiWXNe
lzW2dyhtzhrrW6imA8qyNrQO1MxrFrWh/U1oNGvi5W3oYJccyZrj8s08DoDbssbFPsNNWeNk
I+TrhqxxAqRFfliYNW62kmqKPLcNHe11JVlzWpY1rjbjarImZAUkbfg9eFrQhs62Mxf99Zo/
+jZkBVTXa87n04IiuwOqIn+RA8qcIjvcsd5nzfclWeNyS73Mmi9Lssbpnv/utsSirHEKvBX5
uR3yoplt6PatCW2Rn/K/7lWRP2tDx691INeGj/P2ADsGaiavn7Sh63d3aOY1H19Rcv5yEfKY
12lOkZ0D6WNec4rs/g0y5DGv84ys8fCKG/KY14ys8fE6Ms3kNWUFXJQ1Xl7oRm42yqsh77ah
nzfOBSprjp+8OcQPUJc1KSegLmveuaLk6xWNs7PG2zskSdY8fFRkb8BKU+SQE5AslPsi67LG
42tC52WNR+C8rPH5otVyTht6fRMszZrRK3b+YwG8aorctWHIA6grcvtYrvqKgeeX/b6XNa9c
gO9lTcQGSLMm6rOmytkAaRvKIufhKyOgXChnpMhZzAmoG1Dy/OVfNkBt1uQvv/EB6rImvyQH
PkCaNXLy+mfyjRGQtKEs8j45MwLKIqusyRJWR7Avcp81fyesenCaNY+ywmy+dEWzJm6O5Ddm
QJo1R1JhRt8Ki1TWBI/J6coOKIvcZI2qMKevrZGsSZKv8pNRnL55FAzXUC/sgCRrov4rAKy+
GtVnzUnd3+H1WSs5eY3UVwp4ASvy9sCfHIF9kdWXMrh9/q0Yf+aB3ffpgny475cdULbhgSuw
u8uTXdkCb0X+wRjYFFldreb4ockyIpeCWX47tiDf18LXdwEEEEAAAQQQQAABBBBAAAEEEEAA
AQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBA
AAEEEEAAAQQQQAABBBBAAAEEEEAA7f/+B4k9WFnp4kdqAAAAAElFTkSuQmCC
--------------050509020400040608060005--
|
|
Tue, Sep 12 2006
11:41:33
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 12 Sep 2006 21:41:21 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20060912214121.76120e7a.hamish_nospam@yahoo.com>
|
In-Reply-To |
<45067199.60007@o2.pl>
|
References |
<20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl>
|
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 |
|
Maciej Sieczka wrote:
>
> Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
> same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
> I wonder how such a difference between your and my results is
> possible.
Unless "ditches" is slightly different, I don't know. The 4m buffer blob
seems to me to be the same disease as the lump in "my" area.
maybe try v.build.polyline?
> > But it doesn't matter -- I was looking for a simple example of it
> > going wrong and I think I've found one:
>
> > Can you try buffering this simple polygon and see if it works
> > correctly for you? (I used a 10m buffer) If we can fix the bug
> > causing that, maybe your area filling bug will go away too.
>
> I tried. You can see the result of buffering at 10m on the attached
> screendumps:
>
> hamish_area.png - your input area
> hamish_area_buf10.png - 10m buffer
> hamish_area_both.png - both, overlayed
>
> The 10m buffer is wrong. I'm curious if you obtain *the same* wrong
> buffer.
I get identical results, which is reassuring. (this is cat #1188 or so
from the 'ditches' map)
Hamish
|
|
Tue, Sep 12 2006
15:17:33
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<4506B364.6030108@o2.pl>
|
Date |
Tue, 12 Sep 2006 15:17:24 +0200
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.5 (X11/20060728)
|
MIME-Version |
1.0
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results
|
References |
<20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl> <20060912214121.76120e7a.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060912214121.76120e7a.hamish_nospam@yahoo.com>
|
Content-Type |
text/plain; charset=ISO-8859-2
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Hamish wrote:
> Maciej Sieczka wrote:
>> Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
>> same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
>> I wonder how such a difference between your and my results is
>> possible.
>
> Unless "ditches" is slightly different, I don't know.
My "ditches" is *identical* to what I sent you. Very strange.
> The 4m buffer blob
> seems to me to be the same disease as the lump in "my" area.
>
> maybe try v.build.polyline?
v.build.polylines is buggy, especially for closed lines like area
boundaries:
http://intevation.de/rt/webrt?serial_num=4249
http://intevation.de/rt/webrt?serial_num=4247
and I avoid using it - not to screw my data.
>>> But it doesn't matter -- I was looking for a simple example of it
>>> going wrong and I think I've found one:
>>> Can you try buffering this simple polygon and see if it works
>>> correctly for you? (I used a 10m buffer) If we can fix the bug
>>> causing that, maybe your area filling bug will go away too.
>> I tried. You can see the result of buffering at 10m on the attached
>> screendumps:
>>
>> hamish_area.png - your input area
>> hamish_area_buf10.png - 10m buffer
>> hamish_area_both.png - both, overlayed
>>
>> The 10m buffer is wrong. I'm curious if you obtain *the same* wrong
>> buffer.
>
> I get identical results, which is reassuring. (this is cat #1188 or so
> from the 'ditches' map)
Some good news! Do you maybe have an idea how to fix that?
Maciek
|
|
Wed, Sep 13 2006
06:31:25
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 13 Sep 2006 16:31:13 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-dev@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20060913163113.024664fa.hamish_nospam@yahoo.com>
|
In-Reply-To |
<4506B364.6030108@o2.pl>
|
References |
<20060911194400.1FD111005B4@lists.intevation.de> <20060912152918.77a48f94.hamish_nospam@yahoo.com> <45067199.60007@o2.pl> <20060912214121.76120e7a.hamish_nospam@yahoo.com> <4506B364.6030108@o2.pl>
|
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 |
|
Maciej Sieczka wrote:
> > I get identical results, which is reassuring. (this is cat #1188 or
> > so from the 'ditches' map)
>
> Some good news! Do you maybe have an idea how to fix that?
The loop processing segments sa and sb in clean_parrallel() wraps back
to the first segment, and the bug resets the number of points based on
the last segment seen (ie sa back to "0"), not the maximum number of
points added to the output group. (see debug output in bug history)
(clean_parallel() is in lib/vector/Vlib/buffer.c)
Hopefully that is enough of a clue for someone to find a solution. I
won't have any time to work on it for the next week or two, but would
like to see this fixed and tested for the 6.2.0 release.
Hamish
|
|
Sun, Oct 1 2006
11:00:04
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Sun, 1 Oct 2006 21:58:56 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
Horst.Duester@bd.so.ch, grassuser@grass.itc.it, grass-dev@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS-user] [bug #2765] v.buffer bug??
|
Message-Id |
<20061001215856.10c42969.hamish_nospam@yahoo.com>
|
In-Reply-To |
<44F46348.2010304@o2.pl>
|
References |
<5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch> <20060825151941.48445d86.hamish_nospam@yahoo.com> <44F46348.2010304@o2.pl>
|
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 |
multipart/mixed; boundary="Multipart=_Sun__1_Oct_2006_21_58_56_+1300_niJTwbyyvB_0+JTp"
|
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 |
|
This is a multi-part message in MIME format.
--Multipart=_Sun__1_Oct_2006_21_58_56_+1300_niJTwbyyvB_0+JTp
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bug log:
> http://intevation.de/rt/webrt?serial_num=2765
Hi,
I have a patch I think gets around the famous v.buffer bug (attached),
please test.
I say "gets around" the bug more than solves it, as while I know that
the bug happens when the "sa" segment loops back to "0" and then the
total number of points is set by the final segment number(+2), I don't
really know why, or if this is the problem or the problem is the setting
of npn (total number of points) directly from the seg ID number.
[ lib/vector/Vlib/buffer.c clean_parallel() ]
So this patch just makes sure that we don't set npn from a smaller "sa"
value than was found in the data.
This fixes the buffer for the test polygon found in the bug log.
I don't know if it fixes the hole-gets-filled-in area problem.
Hamish
--Multipart=_Sun__1_Oct_2006_21_58_56_+1300_niJTwbyyvB_0+JTp
Content-Type: text/plain;
name="fix_vbuf.diff"
Content-Disposition: attachment;
filename="fix_vbuf.diff"
Content-Transfer-Encoding: 7bit
Index: lib/vector/Vlib/buffer.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/vector/Vlib/buffer.c,v
retrieving revision 1.7
diff -u -r1.7 buffer.c
--- lib/vector/Vlib/buffer.c 11 Sep 2006 04:35:07 -0000 1.7
+++ lib/vector/Vlib/buffer.c 1 Oct 2006 08:43:52 -0000
@@ -117,6 +117,7 @@
void clean_parallel ( struct line_pnts *Points, struct line_pnts *origPoints,
double d , int rm_end )
{
int i, j, np, npn, sa, sb;
+ int sa_max = 0;
int first=0, current, last, lcount;
double *x, *y, px, py, ix, iy;
static struct line_pnts *sPoints = NULL;
@@ -148,6 +149,10 @@
G_debug (5, " current = %d, last = %d, lcount = %d", current, last,
lcount);
}
if ( lcount == 0 ) { break; } /* loop not found */
+
+ /* ensure sa is monotonically increasing, so npn doesn't reset low */
+ if (sa > sa_max ) sa_max = sa;
+ if (sa < sa_max ) break;
/* remove loop if in buffer */
if ( (sb-sa) == 1 ){ /* neighbouring lines overlap */
--Multipart=_Sun__1_Oct_2006_21_58_56_+1300_niJTwbyyvB_0+JTp--
|
|
Sun, Oct 1 2006
22:27:04
|
|
Mail sent by dylan.beaudette@gmail.com
|
|
Return-Path |
<dylan.beaudette@gmail.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
DomainKey-Signature |
a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DcBg1zoAZSrshPYV75xY6M/FdJloMYQcqdYNNyVi4JmosVbQ2OHXsfSCAMu1QcF0FLt5yzNMqlmV9oA5u8BAEGKQG5Xft1TlJswo5WuO/AnnUsU2b2if0YXv9hQD+78FqWz/D/rATUxT/o7mGGSbRrFPbFbtTXhbGweWI/envdc=
|
Message-ID |
<3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
|
Date |
Sun, 1 Oct 2006 13:27:02 -0700
|
From |
"Dylan Beaudette" <dylan.beaudette@gmail.com>
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Subject |
Re: [GRASS-user] [bug #2765] v.buffer bug??
|
Cc |
"Maciej Sieczka" <tutey@o2.pl>, grassuser@grass.itc.it, Horst.Duester@bd.so.ch, grass-bugs@intevation.de, grass-dev@grass.itc.it
|
In-Reply-To |
<20061001215856.10c42969.hamish_nospam@yahoo.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=ISO-8859-1; format=flowed
|
Content-Transfer-Encoding |
7bit
|
Content-Disposition |
inline
|
References |
<5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch> <20060825151941.48445d86.hamish_nospam@yahoo.com> <44F46348.2010304@o2.pl> <20061001215856.10c42969.hamish_nospam@yahoo.com>
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-4.933 tagged_above=-999 required=3 tests=[BAYES_00=-5, RCVD_BY_IP=0.067]
|
X-Spam-Level |
|
thanks hamish,
will try it out on the latest CVS,
PS: pardon my stupidity, but how would i apply this patch (forgot!)
Dylan
On 10/1/06, Hamish <hamish_nospam@yahoo.com> wrote:
> Bug log:
> > http://intevation.de/rt/webrt?serial_num=2765
>
> Hi,
>
> I have a patch I think gets around the famous v.buffer bug (attached),
> please test.
>
> I say "gets around" the bug more than solves it, as while I know that
> the bug happens when the "sa" segment loops back to "0" and then the
> total number of points is set by the final segment number(+2), I don't
> really know why, or if this is the problem or the problem is the setting
> of npn (total number of points) directly from the seg ID number.
> [ lib/vector/Vlib/buffer.c clean_parallel() ]
>
> So this patch just makes sure that we don't set npn from a smaller "sa"
> value than was found in the data.
>
> This fixes the buffer for the test polygon found in the bug log.
> I don't know if it fixes the hole-gets-filled-in area problem.
>
>
> Hamish
>
>
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>
>
>
>
|
|
Mon, Oct 2 2006
03:24:04
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 2 Oct 2006 14:23:35 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
"Dylan Beaudette" <dylan.beaudette@gmail.com>
|
Cc |
tutey@o2.pl, grassuser@grass.itc.it, Horst.Duester@bd.so.ch, grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-user] [bug #2765] v.buffer bug??
|
Message-Id |
<20061002142335.63636ffe.hamish_nospam@yahoo.com>
|
In-Reply-To |
<3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
|
References |
<5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch> <20060825151941.48445d86.hamish_nospam@yahoo.com> <44F46348.2010304@o2.pl> <20061001215856.10c42969.hamish_nospam@yahoo.com> <3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
|
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 |
|
Dylan Beaudette wrote:
> > > http://intevation.de/rt/webrt?serial_num=2765
> >
> > Hi,
> >
> > I have a patch I think gets around the famous v.buffer bug
> > (attached), please test.
..
> will try it out on the latest CVS,
>
> PS: pardon my stupidity, but how would i apply this patch (forgot!)
cd /where/grass/is/
patch -p0 < patch.diff
cd lib/vector/Vlib/
make
or if that doesn't work and it's small patch like this one, just make
the changes by hand.
Hamish
|
|
Mon, Oct 2 2006
14:24:27
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<452104F6.7070101@o2.pl>
|
Date |
Mon, 02 Oct 2006 14:24:22 +0200
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.7 (X11/20060922)
|
MIME-Version |
1.0
|
To |
Hamish via RT <grass-bugs@intevation.de>
|
Cc |
wqual@gmx.de, grass-dev <grass-dev@grass.itc.it>, Dylan Beaudette <dylan.beaudette@gmail.com>
|
Subject |
Re: [bug #2765] (grass) v.buffer bug??
|
References |
<20061002012404.885D61005D8@lists.intevation.de>
|
In-Reply-To |
<20061002012404.885D61005D8@lists.intevation.de>
|
Content-Type |
multipart/mixed; boundary="------------010306070409050909020807"
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
This is a multi-part message in MIME format.
--------------010306070409050909020807
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Hi Hamish,
Thanks for working on this bug!
I have tried your recent patch you sent.
It improves things a bit, but doesn't solve the bug yet. See the
attached screndumps. These are xcf files, so you extract the v.buffer
syntax used from them.
As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
better - there is no single bulge now, but a buffered ditch. The
problems are that the buffer width is not 4m as declared, but circa 1m
and there is a half-bulge on the left side and some artifact at the
top-left.
In case of the 1m buffer (buf1.xcf) there is no change at all when
compared to the previous result.
If you still have the sample Grass location (vbuffer_bugs) I sent you
please try reproducing these.
Maciek
--------------010306070409050909020807
Content-Type: application/x-bzip;
name="v_buffer_hamishfixes.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="v_buffer_hamishfixes.tar.bz2"
QlpoNjFBWSZTWRooakwANvP////////////////////////////////////3////////4DQv
gj6MD6AA+Kk2EQAEFCFJEFRUlBKBEhABKhEopEpKAdAVEAFAAAZaBShoGfTtyzVJvBwOgeyg
AFAAAACgAAAYgVNvdxweo62BdsnRtgMYSkkRomTGUxHqYp+SeibQmT0ajaZCajT0jHpTaE9D
U9NEwYhMBM0hiGank1B4Qnqep6ammnqehBiHojRiGjT1PU0wIxPSGaJo00ZNME9QeoaBpJBM
amoe0p6aepkn6o9MCjTyR6h6gAADQAaZAAyD1DRkAaAAAAMgADQANMhoBoAaAAepoNAAAAAG
QRBE1HoGqfqR5T0nqemp5qQ0PUxGh6ZpTxIAGhoAGgAAAaAAAAAAAAAAAAAAAAAAAAAAQpJC
INTTQCnphMRmpNPUfqTTGhkeoynqepp6mAmmmhpoAGgA0ADQA0AAA0AAaADQAADQANAAAAAA
KqAEwEwAAAAAAAABMExMAAAAAAJgAAAJgJgAAAJhMABGjJgAAAAAAmCqIhAEACZDQAJhMmgN
ANCYp4mqfo0p+CZMmk9JhMaCan6U/EjKe1MmCaMp7UTMqfsgpsIDKep6Yg1PCNE9FN5TxE9T
0amym0eoJinoeaVMwaIcGP4NMYqkfgsBRySx3GPzlvQsiFAS9GKIYqBmdogw+L4HPMTZNu9M
+96V1TCrsOeoCfMtE8lK4o4ijjpWLHDVGu/PVVRBwjOOYOGcQ2hpHNOaRlOMYkOkfZ/8VRzT
8BLnW+Nl3iNy8RYjIYGb1aeAr+Ik+GmIg71eKIL6TZdwqo6zqPFFxERnJRENw/ceWVGpKH+C
4oiP0HdPsbFjqPXUR9S2gzPhrHF5/+1s2taQe0226WvBFEOId+O5EU+AvUH4LF3zuyuI8FGX
FDC563i4heMBoMCnLqbrhgmEz+nqKzdcq+eS9qPVYlofQUROkhyGz2Gd8JpF8Vf1dXLZXawt
Xa1lqpXSvvatpOk0kOR7UZijEde0xOS0Rlnzue3y/wBK/eRiMr+YZuuoBkHtwJAbkZNFyqoG
ZRat7g4c3kWQSoAkARyc2UJmK4AXFQtwALuNhzvuRBUY0uPsqub8fhRLRiW8RZ87IGO4V7ZB
t+f9s33HugtKCw43df7+UraS1n/e3r1rw4PiYTocCfj4egca2tqTZzsxbl8x338QztT41Q4p
p7A5x0dsou6uc1/J9ze75/EHB3QPS5BeibsjRYPOOsC4XGbGIsLC8uVFUf6GjRLbr4/bLHxX
CUZX5LcFSM8xKH86VEv50ntVrfMwgqXIULfLpfpqPmqwz0vEeMvqmJRQQ0aUHv0qqrlChMxU
js4wphREOsaKiGgoqqiYoTR8hJqzabWJTkVShKWk84dyNBaSlXPUNltW3dysWsYxNYLGJMHV
OgeCfMbl4baryNwe2UfISsQBEeMJYk9QftGD0jiMIgj70wF7iGIwpLCSHsGgiPDSuo+AVQrR
zPhqqs+ilo2/7DCpJ1bfMisbxLSSjjqPjuUsbhwKLWJJmf5LXJZqFmln0plar/epbbnaV8yv
YNBHo3yG0b91L1ToXKZWJ0KX6KjGiqUoyogztKUqMgr+RNiWhNpEM5Lwi+0n7KjQbDTXJWPH
LGYc6tWHxFzkpQvr7G0mZDPZrexZoLU4OC4lPG16MF+9fhSGI2xHyXvVzh3rmBjlt2NsqoY2
3bKoi+jVnRxLyEmRKZmwu/Tl3WjkrC0ad+MCpNNLDYLkbaYiiVt02yam5srZccRe6EwKnSmH
lLFxeYWFhmMkwi84l4vxK86C+pgX9f9al6IjIxMKwvrVEskYFkWGHJUqXQWqQtsq060RahYx
3UmpYpDbzZn2uKuhaW04gMFkzgtta27Ww3RixRcRZeijyEuJZCyYvWLkoVYpoW0TQ4zLcstR
BTURsQqj3AqhISSBgwKDloAMTOlnCILGxYxEXZ0DI49cWoUD+wEBqSmJqJcigJ6KC4pxln18
f0HcyIFVSlnOBIHdAiIIXTF3dECsAqNPfQEB/wUZpK8vTrypKLn73yuMyL6Ur15emVStdayu
hS25JYiFkGYAMgi1QIGAqLKJQ5zbBxKhe+AKsl2lyvrlaUtlv62VMtLbFkUVSlCVGmnCmxKb
VCiykRlsUilFlqyyqkqt02i4ti2ikUkx53lDyxaBNSlEh1gTGiHMsqiMEpWjBhjVFOIVzTYM
GAihihg84jMEJgLKeaRJBAVQjlVAkCFuMChUiuGbuIuYXGXBt5iTmyZsOsaJMLbRgdsRYkh7
9KIenb9RCLCYh0L+FQZHkKIjiLlB5dMRRKEfvpIelZulnVQuSftNwq0OjWsFb+Wm0xPUM1ed
Gd2+O8hnL8YVJS2ZvvXJSSSkiRJnKKIl3KmssUI6tJH5S5REVUUIDvDDBGIZ7MFU3wUKKvj5
Dyk8uBpA2lApBUKoQADdJkoUgO27EUNpQyFRNoOjoe08Yhwk/ViEUmImS+wumb5oErERRz21
23CsZy8lqr785asLV5yVzAuPmMVbxRuVFMrAvr65JjVd6lfWJSRjYJTFE2KJJXJRaUUKpEoY
VBtSVTzySFpfWLr/aJRcYkUsquWPmLyKs+9FGBcotRVKVVFWNRYVW0TVMqKRR0r5C1Vclrmd
hsXnduY8zY/DzLmE6NgXKmgzDOiqiiiiVEqEoz0DPZmgvlrFJeRKDirzNeIsm5RgyXz0LrXS
sPa34YL+bUtJFjftaxZMkYmczwtvTFqLmehRBRVFDtklipKWaxzM7QsGFRy9teiiWdLXZCiU
nULlrLZhlNKKJS5bG+E8d/C1Hbo+M6hovouES7p0rbMErnNM/7KY9y2i1J/O9s882Wu+Y8N5
RcxJYW13hEcqURCiSERv0uUk1Z6E4rtWnVwOJMSWOtgOebgc4pZCCh3BOoNBL00rgkAajA8a
RgDqRppAiAKFXvIHJKFpAWlHUiiLvIoYhRNQiA7QAjQi7RRYuEKSJwA0IZxuoTA5NsYJN64P
SpeSlgSR0g1ew0dEtQsSPosUL+ZYVqrYw2jRGiNARqoKAiiJYLascmCYiCwxMhDQOYoUJE0x
BJgId0f9GCQf9hsBoAiBiEiIhiRaBoQIhOlDQXnfKHuxEcBH3z5iMJ5KwWFhYKohVVYqiqqx
USk+GtEkpSlJQsStSiiiha/ZSoSquWLlFrCiMRjSU3KqMyZiySJRNCEyhtirrX/BGYYEGNIl
JKUokgiCCIQiBOeeoAAV6YNiIYc4oSiUmcUZqiiSUkpUHoVWeRjd2fcaT8DathtGiNNqRJQm
USiJiYmlEa1QekDz/yhrcGGBlvILKCooaKGCKKwcyzHCkwDnnWmIO0G0vF9EGAdjEDYZ6UtZ
pJYixmpbV1iX7LUYlViWRlhmEWzCYomUCuq1meJSRKUSWAREZVEpS2FEkpShsM0zjPYC/OOM
aKw1EJmDgYYWUxhYkSUYOY0EydaDjgRBBJElBElJMxNDATTSTES0BMUjBIQTozImmCChggpI
JKSCSCSgq5po0QPA5oYO7YMBkiCJlFPorqoiMjQZjMMCUqKFpdCEmCIwRDgSYQFKCSAa8KcQ
808KHKHjFhiUSlJLcGmirGlkNBoM5JhbK5YaJY1DZaLZS2Wu0qidPUlBEIiYmIqMFFawiHzf
5Ogc63K4uTEkRmpIPvpfxu9RsNVmZGVRow5VcVQMkZI0hQ0qgMIHlm3ZyUG3MKKthGBmNdGP
aGsZS+yEZVYopiKiz/Q64HNSX5Zm4NTxGB6seWdOcz6Eu1OQzsA5Ry+UGRgZLLmZkZSCGQDA
UX2YjZaJKJQluUpNIolLSXmYx3ypGLEoopBRKYmaS5LmPUfktw4KShc6ROBH45C5Ah6USOYd
QHIaOTezkhGZmAs6LPFzURyEaSNJFrhGywEYomGKEyKUjhpeueH9j7f3WkwXsFJTSJiYlJMx
HHaDft43TUfzEJa5Gel+oYVmJFMaElFFKCKTHw1TTbwwLbkpWxSKUmRw+RiWf9FwpGemLyI6
Jkij0Cl+FUwzDmCxgX5m6UTMSTQmEwhlZjctk0dmYc86s4cVEVxjdrmawPsPzNaJ2qjIggla
DmxzjpzduKLYkJbIhDkOQ5DcRbFsKUp2xwzh2rVszMzSZgxRC5EG0U+eOxuN5WYJEhYYyBhy
ztzqDY3MbmzOWHa/amncG7Ach5QnqgbZNkgNkgMJRlcecdYdOcw3hv31mRcsP3sHUEOycdUa
ya1kMtZlIZKoOJyAchp22gnHgFlpDfHohM07QEbJABijkFCqBjhwOUcR5UTeb982GYP9H6+u
PYSF+ONLiyRSYpKIgpDMb9zjObdmOA6dynPsLHjilHLUUrGma/FWrlxnxLcKZXXLoWywwoTC
KUoIKIz2aNBrL7OZzOYIwGGUypMxSkSmE5ZMQ88DbmobiQD8oEwNxTs4lkqEpgvKIDjJTWzG
JVjGHqziOMiJSlRFC2hZHPLV5Ft6YthRBwGo4JtklpbclSYpMtjcLI98k1UjRYy/F8lEarVN
VqtJfX2qv4CcKSkzSk0lfed+DVuUrkTNykJoRpMLRY1sXXTEzKKTtzjLDsUl9EotuoGC3WHV
mOzbTmRGB9ABMR1515s6AlpTgb9aKaDAaAMPT998VpNjdZYATGRiRAHmjSY6QowYHAyAMFzm
ycRrB2STEwA5MNDowsCKHAcDCXMoXE6RCe7ku2wGM4LjZBzY1oAvTHIDhDGnYzACsBogjAqs
ALw8eqI9Cbbk1YAYNTgvZiadDrGAwAweB4k6s5xvN8Su9sRzMxzBwjKF9AahDRoA0yYjkYZh
kIYwYAYVkYgRgvEWiV03N060uIGBnoD3wfrzYDaKI3IGLOK11IYOI6CwFOyeQj6T4zzCVEWv
YncCwooh9sucBK1/GkvlV5wX13ILi/7fu3/J8dkXmYhoTMaERFEmJ3JmtAxDjQOR6mHA+HM2
IA04tuViqIrEqBSPNsi+1CxK65NaBKiKJiZXGCkwA6Bv7oXtDtA4DwOFIGLGGGxmGhwXElMA
zonEeyHpgdj24jfwGVwJPuTDwptkiTuLBL/k/l6rBPPHGAbogeIxzgjFTmfUgwdMbOwBosO+
DpHiTYLIFs0lSSgUhRVDoDoy5bdBcQpEUQmfWzWGk/7693pCNhEoPWtFQWYMCkTlURHlGyoL
ERMYUfpPMOA+44q1acyouSoSooh2hxnHXNGwGYw8J+gGxttHbZptMErjFh0dOGmzvzEwE0kI
OHWejNjaDbDCyRSYgIp6JwvyvfFznDjtRyHMtVFSxLkLVzJkHGYRiYOE0gj3cICaflT/03Bh
8Mc48cBBBBAQx1AbjutsDj45IxhsEOVKimnwdjvTbZ0+XwNaghkMG8QfM/zn0/IKZq1EZEpZ
qwiD6fo8d5AmFhfZ1i/atKFFhzOaY5EZLhYOZ9oG2nluGGHMHgQ99B2vTG80cHfzcDb1JxZy
+ZmYUkLEZgBQTRE0EsDzS8wMF14vRPIrCqpFJhTUUhWImc7dL+l1K+7RfpCZchTAiVUoJhKk
GBmaOdm496rrMDBLDHRFFYlEKypETLMYEr9Vq0wYFsbBEYDxOk39zi9hvDG3hCOREAKlgH4x
h1nHyBvNkuecDJjTIspIhSSIiR92vOpsmJ5TqUdwX3YuO3rpncNqwnojvTnaquSQTAfizRmn
C5RuOUa3TBuxFnFfABwdE9qPgm48abjIBgl9ILEJEIiYoiOW9WRfSj3bbjivOy7NKlHVqPMn
eJNhW5aowzCPQssVig8EiUQklJIpAEaRemDB0IKL6URFXrw23DukqEU3nzzEIzUmNKJSlJKS
EpOxR5xulSIsSiUkRnpDjrG9Q/tfqH+TCjZXOzQl7t5LrlQlI7dKIf9ktw9So+aled4/9Nyx
LS8xo/aS0EL75zsWefTb19p3T9Z1jqGq4CrIbd3BoH4GmRoG0L6j4zYXlHolrsT6p/OfgHbD
2h1L0JYbZ2h/k5Twlj8B9RvXrl57g+Q6N0XXP8zgn/tlc4q37+BRR89lfLJX3yT7S49Wk5Lm
Cj7j14zB0g59Uf2Lj9E+ydU/QPprX0Hgvz3jvNj4fsKEsw6QOA6ZZBiBuLygoI9FLcAJEui4
CLIsnhms5aaDIixY+o+CLntRgWlEnlT+561axpdki5RuBYqiEfWb1QFzq3VI/DR3C0wpIihL
s0qJSqh5lJ3KUO6Sij8RVVRt0bdsqTQpMoHs6o8R4j18SnVdm7c2TSPzHbmi3AtHXHjMbIj6
jPfeZ38D8NpRWLT4hTYMw69JF10LVCNrMQeAivon8b07VS9S9a1m1KM1JJrKP5WaY/CbZ3qt
9vEPrl5EM5zT1P5V9+NL3KHQhC7L2RRozTGfC4GRDA8HhIi8Jk/c3JXgyv4jdSIfhuubstj+
h0KCg6Ru1NweqScFwkR6xEetRGVAbHf76qEBVUqOrjQEQDEkT2jh4wijLGKCHHoiSnlzqtvJ
EmFAI2Lo3gLiFHptxiRtgpDmmgDfg6NyHUMODAhzuzeF9Do8d6TJqwpzal+OsawvAklSwj6U
IslsUZgSQMcUh587s8hlHzveY/anZOKxPbu+docRf7dEvbPLu7eeb3evEOyWl/RImRMfsdC3
T81+u84vr5fXkGyq/7NRrO/aBfd0/0KHqTAPpeP5h3Z+ovZi8j97uEfrrWVPMp+aUfnjnkPx
TgG+cFFrYGFYvuq7F75pNhLzT6IwjCZ2JPo1h71XbubYDObV1TPOi+W8FxXvDNXGSxyFqPxZ
abIzGmo0jRdri/bTfRxX7h/MPfPgts693jBwnv3WfZUMj375B8psNIwowpOm8ZV36xD+j0xH
vGk9q3y7yyY+AZTSru3sXwmI92557FgL8eAPsGmke7Six5BrOvd64i08Dlv5jrns1rq3IUOw
KqYD4b75RvX3i3+16xwEV7380/oditN/c751rsGIsRc3oUS3ptSx2n+X4l5wH0FIcY0OdeM6
/9vjC89Efk1AQYLHtj6LCjVCbAXSJNifiXZZkOWxoTWGqOWq13ZLzMXjK7d6HRa6MQ/C/qbH
zz57SYjKnbtF4BoFCXgooysqUo1y/DhJzmJ7T9lFkPFP4n/dro0GJvT0Ww9azn3nr1jVWLG6
WN43Rc9QsZGwfpPoEpWNs/LRYSX0VNR3yTI2JbhhmUTEayNullbtVFqNZfbdh8+l80k3Q8o6
lVqowuYb4/xfxm8YV/f+Y6arnH4j76MLXQ1G2Ymofi+HoPCybhu3OtVVc0nBRuDNLUqI3ipw
maJRavuCZ5nnOM1xWk+M9OWa71Cj+JLgJfVcRjRX5T2zr3gs8o3qDNbDXcVyHCVcdRJGcVZT
MXly+ojiv60Wu7S4mJ0TIwsBzaRR/qVFSq4fXVVSllML0SVI4TC59osLgN8RiN8jguGRqnNn
snR5UcE5hGavG1ekZjiktH1hgNl71DcvLbDVRUwKIodslylrWZiOStfiv73XZywvs9WrXSqo
oeoS01zn23RfZDWbluW9JW9w3g8XTzl9mGBpjIsWlq0UYdleRVjZVFiW9M9fNFaqwPNrzC/9
to+635GQfBf8XXubG5P8HxXl2b4Dhns36K8t/He4Ny7Q6Nu9VmHQN298ZzbLjdG7Mb1zNwO3
eyda9K4pjOS8qyKJfXMw47MMp7rP3e9/GXP03xiNfSMPuG8XkfVemKHsnoXTD3lzWeG4z5bI
38xiLjjpdZ1enaBO/CTefOhsobGjYwnVgvFqnQpVUT2sZWWJVYJmA1RrL08ImqUJCshLmPyU
bQklKTpu8QWvIcYH4QzAoQUU4+C4igWpFPyoDQjIYC+heMMna02JzBtIxmf1rnvWk8V5Vmnk
Mj17ZP0EIfRaqTzq1G7IkkSkS3uyfknuX77cDapEobLvkYG7LS00HHb96t46PVI84uFqWF4x
L0x8Dv9/stMysw0B55HyUYmUltjf/3jas5pMI69F8XyXgG/abguC377bgOE7JhepP9aNBifV
URvT0u5dI/RaY0BzxFnN4m/bQ0OCuteKbDzrGxKvwmysHWrUL7YgbsDIkKYYvWZDIkKP4WAh
WE4UWd6ppTIUvQBIgwQfaeqZ9TkN82H0B7T1HnnXHwn8C8NRmCx68/ef5kpS/dI7JfOH85wE
OdR/5ewHQOnfORvnsHoHcY7D894hpzsDQGQkUMAUWaxbdHBF5K4HZmjTCgnyYJ81pAn1WadI
2zjW53ujp23eaYG99fzZ13joxJI6l3bRYjRXMjGwOnZjrj6R5tgaK+3+ouU3e3+Syl5l9V7M
+Y6Vot2/vPdJRHRGJoOnfrGVnMnxH0XLdA++77o/2mVtUnWmRxmy5/X+2/5NRqNdvzM4eNsn
AXGazjs0vfLT0LFGiPPh5Y7E+fH+8dxA9Th0TtjBwg9HFpw9HQRkSajBnrGwtLsKh7X5WYdE
wPoufS6ryxhHXO8UPWPaeJ45xWcwOm2vt97YiHoXHNTRfLZrguA6Rv3sTA27A12loHpkbu43
yJdE3zYWo6NGekj4TOOW/MP+J4XWPLv+mFLdKOdfAUPYyPTzBGo9P0/pLbfv81/A+6dybl3r
Ki+5plUPKy3C+tUPzEb52hvHsWF/1ORymayKIvGBsv9ryV2adMyFqOv6KHjw0XUVUeepBEz1
WzpV3gbO38d8eetY9insuysukuCEDZrr5FuOrKWEDrFLTWGhbrCqYqHayQ8zXlcYYa30r3+v
XLCi/BFk3AMkY6QbJgM+rvEdyqAahcS3RD1waH5DqacOXQODonIwThs1ayEOiiZH5wxAA4kk
wR0/vHwZvG2CmWqSlzLWUcsFLLxqiXxad6N26DxQqOjkjh48RvHA6B08cS8uEo6BvJA+ywRO
Mk4j1EeTUoiIgkgvSAkG8QzZMIN/Aq1ACpUSq8s63od3zOp11PiuJVH1vDmaF6Lz+dr86BYU
sBbShMuXUE9BiACBxPeRDO6kjEKyIlLENnvEoMIwXqyAIxLuFUIzjh9LzmKq7I2b43UiIRvY
3mDnOa3l16UQIX9O5WERC9G201YF6RBbF62ONYWyiC6Od457FSpJUHwdpgKeA+eUROSkok6C
I+hNWSNWbrl7WDiaPENKatIiSQB3T3fd3Zd1vV9NwAeJMV9c0psZ18jpTbSvYaRNgxXyekTY
cV7vSBsZ2UjpE2dK93pBYpodBS2URyLoQqikRHEqG9lbVEcz1R35agcHZXxGgTe4r5TQJsOL
rSoY99iBHIoEtaUFOhExrnOqRMNhTYSTDbN/UsSMYO3O37h2NaOlm1tAahWroFbnaHoGi2e4
IMOhs61m/MNndpNjWDdibFi9AwtRya0jgrE1rLmJVLVpSb8wtsJWQ8ayliYcRaSrCkk0iZJL
tzRWJnyqqxVHcO+dqWRl5yknpwVIq7xMABbAiuigczZp6+g3DZIkiBl4h0FZiB5yR6pQQpRj
ShI2Sr6cIuJJVVBJReCQpxjhxg4fDi7vUZ30LDXJzRRmUM1Oa5i7YU7yJCGFNhTrDCtWllna
4rKtcWwauqqKLV68FYtSevQgc+avXEkgicGuWW9VBWRMegbHNo6CazqXgq1WrzhIgImXZpCh
KoQK2Uycb+uSbAXeBAABACp0tATgCQky29mLS3iiAl0C52gVKIpwUBoyqSLW1mIZKF7buc6Q
Bw5Ry+kBkpzPDeJ6QvUg8Ovt/SFuddJNpHl9Uh1JIRDEJTU8WIaQNxDRFBCxLE1Kyk0hLBMu
yAZBqyXIAwh2TYCpokZmgEkJQKBiRSYghCgRoNJzNPUkAkyTUqRTI0gptSkF+U1jMlW2URn6
GNVMCuxZReog2K2JhBsc/lbAsaqBoRhKQit2IGFTQVYCyocYSC6YMhCpoogpEIaoabU4QlCI
UATpQyRoCgmIIVgwVkSkMnCKFKIlHJcATcIHjhX148HyFAMsUkl5eKqirw4duHofIh4J5ngd
+ezB357oc5QQm2tsbHFEFGQI115vj2RJKcyIWJDRQRIx8GhIwohBDGrkRRBEIjK8u2yDbnny
KGrpvCI4a5HTjP35VuHxcJ9Zhb0uGslDB55lfnN28k/4Lx89DBxtk1CSFCJ2jKlaLxAizNCG
uLQakEa6Tz25c6EfTjBpUbX2C18g/ONFfHrnWfc37SYDlNVfdhteAuepeAe4bCX3nqfNEcUc
R+QwnOMbxjmmcPfuc2gvJSgseobwaqj/FwH+xpNU+4wIxG2Z4xHqkf+ke5Lw0lx06jPSKt46
pGlzn6S1+q9M6s35m5IxmN7N9hK1RVynOs9Hhods1B7l7J1zK0FWMyv5GJmvLdDhYEb19Q9Y
9wO7c+bvtuoYGA12weKzWowl5yTszRVc++6X3Rsi1+o71/a+kvI7rue5RvHFWnfOkFpEo2El
zsXcI4L3LyGE8U2iWifmpYGwuc+b9a7B9lt2mS7ZVEqOWl8I0Wm9O79U+m2EUI8++Io121Nq
KvTqFh59oojzqXZD4L7Y6J/mcy9A9i+y1kPiJbltDwXgtYsNVDRRrI1HgrlSXEKqLUSWJRtE
lUpVSuKFEqn5BjUeCkql2b4iWaQ1ktVLjpWpctL45co/kS/6v9z3iI3pnvmv6F44yUfupfBf
wqLxqGDBJIUdAhySGZ+QvJ40h1z2CCF50xoNSEKUyhyRsQB/K00b5kfNfdaqKryxuXTLXFYG
glQ+mwvEZ7lIhHtHUqIeWYlEQ6xa9Iq/HSerSfJf/Wa/ufEfldMnum5VUYCI8w2VHn0nPpd4
kb1Jzzs3Ff2MC1GuOOeWclyWEud+6h6RV2qTx0sxEkpYjpnHcVyXcpWlVX5Dzrzj5Lp28XL7
6yrv1rCxP4no1xU7sool/clc88Uct7Zu2VY7AiJaSWcl6x5D+xnuneXRc8hJiRnPDdq4btVy
jpku2dgRKjgJcM+EovryiUiiViqiVyqqX7CiPaJWvNP97z6i8tYCT3Lu1FVFHGWrFGBnPBeM
sM1D4qGilhIYHZMJuXPHxnm0WHbo6M7J1C8jwHQIudaSj5Zjdkwv8F5YaJoo0WizW4R7rk5w
ERGii4CIiiM5B36jCi+jVAiI1SV4xKG1bZY5wz2B5xx1rqFjtUsCrK470T7ztXHcNzTvnnVV
j7DUffbojdusUOClYlFqUdglDySR68f4tBlajmXWHht+j2T0C51p/SoWvZo3Zru0bZzjv2A5
hvjmDfHv0quG6Ao5pJtz9e+q5lLCqekYG1PWPoNl7hzrXeiS9Oyu7c0uKLT4beKsLyj27ePK
PFPEcy12s6Fug5KTzaqiNZ1DpFTpkowOrb1gdM7I+Cl/+Nd/E6d58q3ZLgLz1ZpsLhGVREly
reOKodk2zmHGWJcZQsL7UjVbRRlWMa8iiVXFUWP/p/4aL2jE69qPBcZhct07A7p5VecVa8F+
O/mNM472TE4KMT0zXXmY/8rkcpLTJWpaDlr6p9pc3qUapRsvtM1yj3qFhuGRwFFEbx17tlXm
nBcFVgaTMdd0L5LhsjiMD5bjP5X3X4z3bAyn1m0d45l9Nz7C+s/qXjCwnhkt8RvkJUcsq3yx
RRYqlnDt3t2gWNy3b5TcNdV36jfLmBc3a19JhhDwf1ikp7N8NJLgJaqxLs1Ec201G8b9kSVN
q4DA4L5r95+6wMkSZcH5nLHRMDY2Y/myJghCLJUzg2PFLEZkGRhUl0MTYdElkZXfqty/LRHx
CI/3DK5pRR5pCG0NoYGNx3yWo2HyHhOS7NYvpck5JQ4/E3KOQUWOO5T+lJmLWNR3C1qJWG2O
SoltihwS5lWqqNZH+lzbPS0WBotAxOrlDvUnaJRpswvoiUZqxR7okUJFHzkVHQsajzCSSSUv
D+Wg2yYlMRVqthtnAR65Vt2UcJfJXyVEpJJFHStBEVb9awncHDaRc4b5guSvtVJ4CLm7b9um
6aTcn+ki8lKLzPfhPFaK1KXuWNQ9GvBRazzNaZY7B2URRMdy8khVmoxthvG4di46V5KQtSZj
MKEaLNUMSPGUaC5xm0azWLiI4vifpNlujdrijNSolrqPWo3iwtYl9tFrAwM1nsTokjUbsYpK
sTUYTIarEY1rMPjolzhjKkL7EZp68jmxfHRoylz7BiOGvucLWobg1CqN1nX3xarVw3LTbtYw
ES12k1Gi1l8vQayxaUVUar8BK0sEkrDVRu27WDdtIUEOl1VdNZBgYlFhmsYsVyHhIutWtqvM
K0iL4YUUM9JpKFGi2HIbhpmVlJZUl9YwNQsVWMkRU75El5aYmk1Go6NH/8WMSiR/sQz7B32V
pREJgSfPZhGil+WLYQQJTCIgblESiIRaSz2e2jUMChtSM0wsSItX19eX2obhRqNowMRVkikw
iMbKyLiKoqjIyLGRiLUIEXJRBAvMEYGVvEb4wlpGNJvmVt2+a6N6ufFSkk1ZhEwlH6r9C8bV
GcHERDh8sGi70JiMBRU44BEGhUooAoAEpUKRFlSqShQKFAKQVKVAEYEPCB4Y5YeEmMKYi1pE
aBoGi11VsLoTsNoiL7WWi1EkIyzBBMwhDOkYCWV5mhw0srZfvtszWe4foPbGAlMZCUajyzpW
4aNuNYoj+REm2Sk31X9JTOdSYknWDRPS53TlCW0KMSowMDIRUvFpcVLlVybLFLblSXkk7ltG
ucI3TYb1eglEpSSSJSlCRKSTCEQcsgwJIkIIEkIIhiEmVlWLELEpX1BFEpTEJS1iRUk0ETA8
DjNOhYkIgDcEEaMAjcYJgQ843BF12GRzzgYmiYkMO5niGnNgXJkxWwWUUDe2N4rN/WYTmaN9
mksGEVhYDjvyuUqd2T/9WTwEXxanl7noIedQ6xLI3LdfX7wnpd55rUxNfBgmUF6ExzrLCQwB
gRiMCTqnCxY2XQBPQGmJxSYTcDnP0mcKwZCFEI/wC1goCiKMSddPVSZ17lVHXa6AqPZCwICP
IoaBfEpcoOUHI0RoF5QaA4CVQ1KEaFyhGIcxKZJQSVSsRug5HKNQkBspCQHMiYsQuUqJMqUl
0l5pKNJpJnUpVI4R08MGkwjocjlGaOyw0u4dUrsdqIAeAq8ihQoU7ePiCyzJV5MoJnk3y6Yw
0QRCIk/rTDqOZ5WLDj1KVSxygopEUvwhzHV6sajoY6O+xYsOPHCEqRSTGiOc2MdvG53V6LMx
IJlNxhQ5MuFxNroskpwX4dFWcUYkLZiNrSkziR+ESbvVtvr+pRQX5RSlk3ojkcPW1LLc03uY
q0+jY0JyRSy+jjcnmd02ulqYoMmOjGYoaXK5WG6/eM+e/sIIhERFDQBNg4qvJkXVDECdSQBf
zhwLzJYmMlmXk8lfjaa+K1FaZJdIyLw6tI7jt4btHWtLPY+FSZKUAJiNgRdBcgpAM4MIB7aJ
IRoGkEzWUvpIkSEjfpAZwkGJEVDC4DRGPUFEBWIWAIXEgSEcuDiOwORQAqkCRYskQawV0JEj
5t75yQiuTANioSg3a2DWk8tuUtbIax0p4GymxinkM0IuxIyEGcECyQjIQgYqCUcEqpzBDEgM
LrGWlaa3v3w5dOn5fB5fT87dzeCENBKkc8oHU2UFerTFID4CQJ5MPAMQeGWC+DnldC+SxxQx
8lgoEdvgnMYABz2EwEQOoxMR2qKSJVE1mC9WSnVdX4DoEwPI4Kc/Ot1xECdbpw1KnOgEDrUg
VE1Kp2J5PDUqsRSAGdl2JsbCJp7LEA2zFA2dOIuLU9kS9xoMJIUuzbECioCTx/S+R6raWtLW
1FXQoJiCZ62T9yft9jQW6lP6uBTjzh38tCa2Fly4XKSkBQPFIO3SlLB1FDxmtLOYSUaTV/jW
SPb9jW8CxfYITvQjvRjvQ9lPJG2xMd+ejMOAQB5sqLz2edNNJnKoiUhCIjjJQ0SiqpYojj8N
ziyweXzi9Y57aa1iJhzvZ6qti7o6orMJ2pagiER2WTyHGnCOGUgWxzRM8X3nHpYg7zbqNhdc
9XzgcieF6GHd7IeBOjoThFNJFB5vMqKSIlDirrJDBAhFhRYkNjbww09cGrehUSkKZmhRKZ5b
U7GG7tMyUHhD1EoHCNiUoTkzJCFglN0plCkVSlBSpQBQJS+wRkBQVS1WkCkSJZlKpmbnTjsF
tsoWSgbeYrCI2JRxpIv7qg6evTXgGZF09eJAsSHsYkDMm9fDiQJaF5Vvpa1lQN3qxUgZUil5
bPOISvndxxYPDm9HbfseccHIeKFe0lNNMr5mMSIJEKAGgaCE4+x9Z12XUcabjndPhm6Q317H
2Bh1l00ARDTEwEIGoMqYpDfBirBJ2sgdVCD21ugDdIHFBkEzTBMxQXW9O7/Mczi7nhx3cXVy
r10D5uQDa5ry/MdLDmvmubcEOOpCIApCJSgoq5eYI8IHso718WdV0ejv8V0ds7A7PfcLg7rb
b7fYIwzHIYxSRROlqb+wNmgbahDaBaTr0gSHWbWlAptpDa0gdZSIN4oE7+aSFN5Ib6gb3kNt
tm45EknBjcNxuOJuWxu91zGKtNpRyyHMYqapz+Oy7YKyEMhXAUAaGL/LZWyhJogM4RAf/F3J
FOFCQGihqTA=
--------------010306070409050909020807--
|
|
Wed, Oct 4 2006
00:18:24
|
|
Mail sent by dylan.beaudette@gmail.com
|
|
Return-Path |
<dylan.beaudette@gmail.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Dylan Beaudette <dylan.beaudette@gmail.com>
|
Reply-To |
dylan.beaudette@gmail.com
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Subject |
Re: [GRASS-user] [bug #2765] v.buffer bug??
|
Date |
Tue, 3 Oct 2006 15:43:29 -0700
|
User-Agent |
KMail/1.9.4
|
Cc |
tutey@o2.pl, grassuser@grass.itc.it, Horst.Duester@bd.so.ch, grass-bugs@intevation.de, grass-dev@grass.itc.it
|
References |
<5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch> <3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com> <20061002142335.63636ffe.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061002142335.63636ffe.hamish_nospam@yahoo.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset="iso-8859-1"
|
Content-Transfer-Encoding |
7bit
|
Content-Disposition |
inline
|
Message-Id |
<200610031543.29945.dylan.beaudette@gmail.com>
|
X-Scanned-By |
MIMEDefang 2.49 on 128.120.32.41
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Thanks Hamish,
I have applied the patch, and run v.buffer on a sample data set, and all seems
to be well. however my sample data was a set of line segments: and not areas,
as was the case with Macieck.
Perhaps this test case is known.
Cheers,
Dylan
On Sunday 01 October 2006 18:23, Hamish wrote:
> Dylan Beaudette wrote:
> > > > http://intevation.de/rt/webrt?serial_num=2765
> > >
> > > Hi,
> > >
> > > I have a patch I think gets around the famous v.buffer bug
> > > (attached), please test.
>
> ..
>
> > will try it out on the latest CVS,
> >
> > PS: pardon my stupidity, but how would i apply this patch (forgot!)
>
> cd /where/grass/is/
> patch -p0 < patch.diff
> cd lib/vector/Vlib/
> make
>
>
> or if that doesn't work and it's small patch like this one, just make
> the changes by hand.
>
>
> Hamish
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
|
|
Sun, Oct 8 2006
13:22:09
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 9 Oct 2006 00:21:49 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, wqual@gmx.de, grass-dev@grass.itc.it, dylan.beaudette@gmail.com
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
|
Message-Id |
<20061009002149.6e81787a.hamish_nospam@yahoo.com>
|
In-Reply-To |
<452104F6.7070101@o2.pl>
|
References |
<20061002012404.885D61005D8@lists.intevation.de> <452104F6.7070101@o2.pl>
|
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 |
|
Maciej Sieczka wrote:
> I have tried your recent patch you sent.
>
> It improves things a bit, but doesn't solve the bug yet. See the
> attached screndumps. These are xcf files, so you extract the v.buffer
> syntax used from them.
>
> As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
> better - there is no single bulge now, but a buffered ditch. The
> problems are that the buffer width is not 4m as declared, but circa 1m
> and there is a half-bulge on the left side and some artifact at the
> top-left.
>
> In case of the 1m buffer (buf1.xcf) there is no change at all when
> compared to the previous result.
>
> If you still have the sample Grass location (vbuffer_bugs) I sent you
> please try reproducing these.
patch applied to 6.3-cvs and 6.2 branch.
square_rot_buf30 is fixed.
ditch_1188 is fixed.
1 and 4m buffer around ditches seem to work fine for me, but they did
before the patch. (?) (command taken from "v.info -h ditches_buf1")
I still see the "holes get filled" bug in my own data though,
(v.buffer in=roads bufcol="LANE_COUNT")
so that one's still open.
I seem to remeber Radim commenting on this a long time ago, here we go,
complete with screenshots:
http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
http://thread.gmane.org/gmane.comp.gis.grass.devel/9506
This is probably the same bug in v.buffer as you see and nothing to do
with buffcol= (??).
Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
is an interior dangle in my road network ... and I've isolated it to a
vector made up of 10 polylines.
can you try buffering your ditches after
v.clean tool=rmdangle thresh=[big]
?
I don't understand why you consistently get the error, and I
don't, using the same* dataset. [*] are we really using the same data?
md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2
Hamish
|
|
Sun, Oct 8 2006
16:27:22
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<45290AC4.5010509@o2.pl>
|
Date |
Sun, 08 Oct 2006 16:27:16 +0200
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.7 (X11/20060922)
|
MIME-Version |
1.0
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, wqual@gmx.de, grass-dev@grass.itc.it, dylan.beaudette@gmail.com
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
|
References |
<20061002012404.885D61005D8@lists.intevation.de> <452104F6.7070101@o2.pl> <20061009002149.6e81787a.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061009002149.6e81787a.hamish_nospam@yahoo.com>
|
Content-Type |
text/plain; charset=ISO-8859-2
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Hamish wrote:
> patch applied to 6.3-cvs and 6.2 branch.
>
> square_rot_buf30 is fixed.
Confirmed. Great!
> ditch_1188 is fixed.
Confirmed. Yay.
> 1 and 4m buffer around ditches seem to work fine for me, but they did
> before the patch. (?) (command taken from "v.info -h ditches_buf1")
>
>
> I still see the "holes get filled" bug in my own data though,
> (v.buffer in=roads bufcol="LANE_COUNT")
>
> so that one's still open.
>
> I seem to remeber Radim commenting on this a long time ago, here we go,
> complete with screenshots:
> http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
> http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
> http://thread.gmane.org/gmane.comp.gis.grass.devel/9506
>
>
> This is probably the same bug in v.buffer as you see and nothing to do
> with buffcol= (??).
>
> Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
> is an interior dangle in my road network ... and I've isolated it to a
> vector made up of 10 polylines.
>
> can you try buffering your ditches after
> v.clean tool=rmdangle thresh=[big]
I tried with tresh=1000. Nothing was modified (Removed dangles: 0
removed lines: 0).
> I don't understand why you consistently get the error, and I
> don't, using the same* dataset. [*] are we really using the same data?
>
> md5sum vbuffer_bugs.tar.bz2
> d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2
Yes, we are using the same:
$ shoofi@sorbus:~/tmp$ md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2
Very strange. Maybe it has something to do with the compiler used?
$ gcc -v
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Or locale? I'm from Poland, where we use "," instead of "." for decimal
point delimiter. But how that would impact v.buffer I don't know - just
trying to think of *something*.
Does v.buffer depend on anything that could differ between your and my
system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is yours?
Maciek
|
|
Mon, Oct 9 2006
08:02:33
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 9 Oct 2006 19:02:13 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
bug in Vect_break_lines() ? [bug #2765] [was: v.buffer bug]
|
Message-Id |
<20061009190213.1f2e84c8.hamish_nospam@yahoo.com>
|
In-Reply-To |
<45290AC4.5010509@o2.pl>
|
References |
<20061002012404.885D61005D8@lists.intevation.de> <452104F6.7070101@o2.pl> <20061009002149.6e81787a.hamish_nospam@yahoo.com> <45290AC4.5010509@o2.pl>
|
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 |
multipart/mixed; boundary="Multipart=_Mon__9_Oct_2006_19_02_13_+1300_hXai4=qcl+5ri_oU"
|
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 |
|
This is a multi-part message in MIME format.
--Multipart=_Mon__9_Oct_2006_19_02_13_+1300_hXai4=qcl+5ri_oU
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Hamish wrote:
> > I still see the "holes get filled" bug in my own data though,
..
> > Ahh, I've got you now Obi Wan, the interior-fill bug happens when
> > there is an interior dangle in my road network ... and I've isolated
> > it to a vector made up of 10 polylines.
attached are instructions for recreating the bug with a simplified set
of lines which trigger it. ("v.clean tool=prune" worked well!)
Things start to go wrong in Vect_break_lines(): the island (hole) in the
middle of the area (test with d.what.vect) becomes an area, so then
area_in_buffer() loops through it as a real overlapping area. Then the
island's centroid is nearer to a boundary than the buffer distance,
which lets it pass the test. Perhaps area_in_buffer() could test cw vs
ccw side of polygon to solve this?
I get the same results if I stop v.buffer with debug=buffer and run
"v.clean tool=break".
also in the Vect_break_lines() step it goes from 8 boundaries to 167,
so I can't later pass a stored buffer value for each of the 8 buffers to
the area_in_buffer() test (but this may not be important if it knows
that the island isn't an area in the first place). It's still a bug that
the dynamic buffer size area_in_buffer() uses the last buffer &
tolerance loaded for post-processing, as I've noted in the source.
> > I don't understand why you consistently get the error, and I
> > don't, using the same* dataset.
..
> Very strange. Maybe it has something to do with the compiler used?
>
> $ gcc -v
> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
>
> Or locale? I'm from Poland, where we use "," instead of "." for
> decimal point delimiter. But how that would impact v.buffer I don't
> know - just trying to think of *something*.
>
> Does v.buffer depend on anything that could differ between your and my
> system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is
> yours?
No idea. I'm using Debian/Sarge, gcc 3.3.5, linux 2.4.27-3-686 on a P4.
Can you try running
v.buffer ditches buffer=4 debug=buffer
? and have a look at the output with d.vect and d.what.vect ?
maybe some clues/hope there.
Hamish
--Multipart=_Mon__9_Oct_2006_19_02_13_+1300_hXai4=qcl+5ri_oU
Content-Type: text/plain;
name="vbuf_fill_bug.txt"
Content-Disposition: attachment;
filename="vbuf_fill_bug.txt"
Content-Transfer-Encoding: 7bit
cat << EOF > vbuf_fill_bug.vasc
L 2 1
1772686.30519775 5851775.14702921
1773306.00632122 5852447.04425756
1 1
L 2 1
1774243.98302532 5850080.4624088
1773306.00632122 5852447.04425756
1 2
L 2 1
1773306.00632122 5852447.04425756
1773195.48790797 5853628.13605358
1 3
L 4 1
1773145.65706623 5849811.18970544
1771278.44193002 5850577.88976232
1771661.0129225 5852557.45636742
1773195.48790797 5853628.13605358
1 4
L 2 1
1773145.65706623 5849811.18970544
1774243.98302532 5850080.4624088
1 5
L 2 1
1773218.55495855 5849304
1773145.65706623 5849811.18970544
1 6
L 2 1
1773195.48790797 5853628.13605358
1774528 5854386.23216845
1 7
L 2 1
1774243.98302532 5850080.4624088
1774528 5850056.01304682
1 8
EOF
OUTMAP="vbuf_fill_bug"
v.in.ascii -n in=vbuf_fill_bug.vasc out="$OUTMAP" format=standard
ATTR_COLS="CAT int, ID int, LANE_COUNT int"
v.db.addtable map="$OUTMAP" columns="$ATTR_COLS"
db.execute << EOF
UPDATE $OUTMAP SET id=16029, lane_count=1 WHERE cat=1;
UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=2;
UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=3;
UPDATE $OUTMAP SET id=6, lane_count=2 WHERE cat=4;
UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=5;
UPDATE $OUTMAP SET id=6, lane_count=2 WHERE cat=6;
UPDATE $OUTMAP SET id=6, lane_count=2 WHERE cat=7;
UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=8;
EOF
# demonstation of buggy output
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn bufcol=LANE_COUNT scale=150
# stop processing after buffering, before cleaning
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn_DBGb bufcol=LANE_COUNT \
scale=150 debug=buffer
# 8 boundaries: how to associate the 8 lane_count values for area_in_buffer()
?
v.info -t ${OUTMAP}_buf_dyn_DBGb
# notice center hole is not reported an Area
d.vect ${OUTMAP}_buf_dyn_DBGb
d.what.vect
### No good: tool=break makes island into an area,
### and makes relating 8 parent polygons to lane_count ?? v.distance ??
# break at intersections
v.clean in=${OUTMAP}_buf_dyn_DBGb out=${OUTMAP}_bdy tool=break
# add centroids
v.category in=${OUTMAP}_bdy out=${OUTMAP}_area step=0
# result: same as v.buffer without debug:
v.dissolve in=${OUTMAP}_area out=${OUTMAP}_final
--Multipart=_Mon__9_Oct_2006_19_02_13_+1300_hXai4=qcl+5ri_oU--
|
|
Mon, Oct 9 2006
18:36:58
|
|
Mail sent by tutey@o2.pl
|
|
Return-Path |
<tutey@o2.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<452A7AA1.30209@o2.pl>
|
Date |
Mon, 09 Oct 2006 18:36:49 +0200
|
From |
Maciej Sieczka <tutey@o2.pl>
|
User-Agent |
Thunderbird 1.5.0.7 (X11/20060922)
|
MIME-Version |
1.0
|
To |
Hamish via RT <grass-bugs@intevation.de>
|
Cc |
wqual@gmx.de, Hamish Bowman <hamish_nospam@yahoo.com>
|
Subject |
Re: [bug #2765] (grass) [was: v.buffer bug]
|
References |
<20061009060233.5CC7F1005A8@lists.intevation.de>
|
In-Reply-To |
<20061009060233.5CC7F1005A8@lists.intevation.de>
|
Content-Type |
text/plain; charset=ISO-8859-2
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Hamish via RT wrote:
>> Hamish wrote:
>>> I still see the "holes get filled" bug in my own data though,
> .
>>> Ahh, I've got you now Obi Wan, the interior-fill bug happens when
>>> there is an interior dangle in my road network ... and I've isolated
>>> it to a vector made up of 10 polylines.
>
> attached are instructions for recreating the bug with a simplified set
> of lines which trigger it. ("v.clean tool=prune" worked well!)
Good for you. What does the tresh mean for tool=prune?
snip snip ...
>> Does v.buffer depend on anything that could differ between your and my
>> system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is
>> yours?
> No idea. I'm using Debian/Sarge, gcc 3.3.5, linux 2.4.27-3-686 on a P4.
>
> Can you try running
> v.buffer ditches buffer=4 debug=buffer
> ? and have a look at the output with d.vect and d.what.vect ?
> maybe some clues/hope there.
I might have some time next week.
Maciek
|
|
Tue, Oct 10 2006
08:41:10
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 10 Oct 2006 19:40:47 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
|
Message-Id |
<20061010194047.5b9445d0.hamish_nospam@yahoo.com>
|
In-Reply-To |
<452104F6.7070101@o2.pl>
|
References |
<20061002012404.885D61005D8@lists.intevation.de> <452104F6.7070101@o2.pl>
|
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 |
multipart/mixed; boundary="Multipart=_Tue__10_Oct_2006_19_40_47_+1300_KR6QajtdOtIE+RE_"
|
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 |
|
This is a multi-part message in MIME format.
--Multipart=_Tue__10_Oct_2006_19_40_47_+1300_KR6QajtdOtIE+RE_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2765
just to recap on the current status of the bug:
if you buffer a polygon which contains a interior dangle that is near
the middle of the area, one of the cleaning steps* makes a mistake and
thinks the temporary island centroid is within the buffered polygon.
This happens when the distance to the (exterior) centroid is within the
buffer distance to the dangle's new buffered boundary.
(see attached pic)
[*] area_in_buffer() {first test} in vector/v.buffer/main.c
in hind sight I think Vect_break_lines() is working correctly. The
original unbroken boundaries are on top of each other, but do not
"touch", so interior area has a path out. After breaking lines at
intersections the map is "flat" and there is no way out. (think
"flatten layers" in gimp)
buffer distance in the cleaning step when using bufcol= param is also
buggy. (only uses the last buffer value loaded)
Hamish
--Multipart=_Tue__10_Oct_2006_19_40_47_+1300_KR6QajtdOtIE+RE_
Content-Type: image/png;
name="vbuff_fill_bug.png"
Content-Disposition: attachment;
filename="vbuff_fill_bug.png"
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAi4AAAKkAgMAAABaD1zyAAAADFBMVEUAAAC8AADIyMj///8MINsn
AAAZN0lEQVR4nO3dS4/jOH4AcK0nh4ouAyxyCOZU48UOPLzkkGsAL3Ia9HGQaizq2KeBPoXh2QRu
IkCARbbRqJOH2SrQ/BSDPgW+5KsUOtcCesWHJD4lvkR5ps3d6a6S1dbP5J9/Ug9L1afLKc/V0gKp
XDGucsW4yhXjKleMq1wxrnLFuMoV4ypXjKtcMa5yxbjKFeMqV4yrXDGucsW4SnnMz1X1heOl4phn
QAh2aIpjakKcmtKYZ8IK3l4C5swx5McLwLwAMlI1hTEfSFf+a3FMXzGE/M/imI+9heDFMfWAIduF
Mc+SxRY0RTFyxdiCpiTmRbbYgqYk5oOCsQRNQYzUrx1BUxCjVcyyGK1iLBFcDvNMLghT6xizOxXD
GBVj6U7FMOcLwuj92tqdSmH0fr0kxlYxi2E+Wixm3y6EMfr1ghhLv14OY62YhTAvVouZgotgbP16
KYy1Xy+FcVTMMhhHxSyCMfr1w4KYWrOcmuUwRsW8W7CZzq6KWSDpGf36iSyHMfr1/XIYo2IeyXIY
YyJzvyCm1sOXLIdx92tSftppVEyzHMaYyMgVUxpj9Gu5YgrvxI316+KYkYRXHGNUzEn5rexRCCPh
vVsQU+sVo4Rv2YNFowmPFD6mp1eM2q/LHno1Et4jWQ4z0a+LHiGfSHhlzx0YFfOg/V7yrIpeMVq/
Lnq+aapfFz0TV09VjO1c8kwYo2Ke9AXbcpizvm2tX1tbaSbMZL+2nkmeCTOV8Aj5shhmYiLTlqP1
382CmZjIuCpmHkytV0yjLbCG7zwYtV8jgoyKsV6wMg9GrRhMoFEx22IYfSIDfu9ZMXNg9H59MPr1
thhmOuHZ+/UsGCPhvdcX2Pv1LBi9Yk6NtsRZMfkxxnj93wSqC2xXW82EqfWKedNmGrm4+vUMmOmJ
jKtfz4A569s2JjLbYpjpfj1SMbkxkzsozoSXH2NOZBptgbtfZ8fETmRmwdRJFZMXM92v3QkvO6Y+
VmrdhPTrzJiXY02OlbTtoH6dGfMzqxapbgIrJifmhTOOQ/jqFWPdc5sH0yW8vmrC+nVWTJ/wukE6
sF9nxfQJD8dWTEbMELiiivSKcey5zYGRdlD27M/Qfp0TI43XvJ1C+3VOTC1tF8RVTDaMMnmAJHAi
kxnzQcagmH6dEbMhKia8X+fDPCu7IziuYnJhzlDZNAicyGTFvAAVAyP6dTbMR5F1q4r//e96xXj0
62yYM89z7exhx374Pqpi8mBeAMfQtqrb/05Yw/hVTB7MRz5twIDXDnmnY7YFMTXH8O4NaL8GisWr
X2fCvAgHFG31RDSMT8LLhfkgHFyA6HitYHwrJgsGqJjHvpJE8Up4mTAvYuMiavG9hvHs13kwH0Sl
iOHpRDSMZ7/OgwEq5l07NEBp3PSvmAyY5y5ceG2cGoAIkDBTe25ZMWcV844AjOUDnL79OgeGzze7
pqI7KICsJYx3v86B4ftuPeaR1hCUMAEVk45hrYQ7EE14UK6Z6T23jBjeSj2GJTw5Zvz7dQYMb6Ue
Q3dQoNSbAvp1BkytYE4s+0p5JqhiUjFiD7vDPD2ILt5htiUxH1TM/YOAoPB+nY4BCuZENExIv07G
9Ad+eZ55Qg9IxgRWTCLmLGMgucdPkEMgW+o9kcmCAQqmnTx8AyRMWL9OxQyH5xmm3dn/E5EwYf06
FXNWMQ0/WdBhgismCSMdIKIbp/u0cs0ETGQyYKSzS3TjtFt3MQPC+3UiplYwp1dty3S9CYT36zSM
fDVIC2COJ8QzIIipmBTMRxXzQJuKBjBm/4+omBSM1ErswJmKCU14aRjlmh3cMtCAQRH9OgmjnsIG
9wxz6jDBCS8NAxTMWyJjYFTFxGO0M7XvFAwIT3hJmLOKeaNiIvp1CkZtpUcsY3BMv07AaK300Ka5
AYPiKiYao7VSI/Yi2fEQcIh7z1iMdjnII7tqkmMw2bjuCjcTRrsc5IE1jqgZcLsti6kVCzuHwg5M
UwyMrZhIjHb5JjuHsu8waFsWo7USO4eCNzySybEwRmsl/teOY/CqLEZrJXEKkJ06aMi+jswykRjt
mrNGYGjVNPgW/HNRDLC1Utu5K0Ca/YH8S0mMOWALDKmqP2xA1CQvGnO2thKbVKEGxc04YzHmUNBj
MGzqshhzKOgxBPxAymLUVhpOp7Oa+deyGK2VhtPpPGbKYmxDQYeB+KEsplZbSfoZELD/qijGNmD3
GALK1ow2FNwrmCMpi1HDV7lIEbQT4aIY+4AtMO24TTFxe3ARGPuALTCIlMWoraRecgbqshhj300u
G1IWc1bDV2klsiqLcQ4FvJnKYlwDNitHIHyFMKOtBMtiJlqpLMY5YLNWImUxtdpKKg2yY/bFMGND
Ad2FK4oZGwroAZEOE3SWPxYDlK1rVx/XZTFaK6lJBpOyGLWVtCSDCmPUVtKSTF0WMzpgs7PsFHMq
gzmPtdK+LGZ6wC6ImRgKaEHFMLXaSioNlsWMDgX9JaaFMForNZZWGk4ebGfGqK2kDQWwLGZ8KABl
MVMDdlEMGGulrgkLYaaHgr6GmtkxZ2XrlgG7JEZtJcuAPVTR7BitldShAKs/zY7RWkml7ctitAHb
OhQUw4wOBVj9MenkgQ+m9mslhsH0MpoZMT4DttRMYFaMz4A9YL4js2LUVrIP2APmzawYrwF7aLL3
s2Im991UzFdgTozy2fWhACq/tatieoXcbJjxoUCVtr+xy5Nnw5zVVlJpaiv1hztnw4y2Ul0W4zlg
q5jYQ1dTmNFW2qu/zo3xHbCLYHwH7CIYtZW0oUBvpf566ZkwakNoNxHQWyn52Os4Rh2XtKHgSPQy
L0YNmdGhYH7MOaiVZsYo25tspXkxashMtlJJzOiArWBiD12NYpT4HR+w58ec5S1pQ0FtwfTX18+B
UVqiUVvJYimHeTS3WxSjxK+WZGytlHzs1Rvj0UrFMFMD9uwYuWdPDgUFMdNDQUHM9FBQEKPd3Mbe
ShSD3qLDLJjz0ErqRh2tRPvY5qd6DcF2Tow2FDhaiX73AH5dwU3sQT0/TKNu09FK9MsY6De3tyj2
Yn8vjMeAzTEI3v6mqmo4A6avAI8Bm2Mw2t28qerNnBitlVwW2kzVzXfVbo6vFHUYnwFbYA4V+u72
CCOvr/fB+AzYAnNc3bw53Gwiv3kQjnG3UvvSbg1fgZvVl9vcmH7QVjH2AVtgVhvUYLTP30w9plG2
CIi7bAAETdu/8zeTHTPSSgTcAtSuvTnm7012zEgrEXjL1kawFGasldCKrQ1vfvy/3Jh+BiFjXAM2
K5hj2jy8nQujjExwFFMT1vcO/xllCcU4B2xebS0GPkACvtiWwLiHAlr2K3q8HkTcniIKM9pKpL5p
6+59u9bvsgfw2cSMtxIG9Crc37bNFfntxTDMeCuh7kDwLjLreWCk3ZR6HAPpHTO/b2PntgBmbCho
C9yDmpz+2g5R+fOMiRkbCtoCjgdAnp4AgVUBDBi1YIKrNmROEB/z10y36adha6MFsa9BNG28366y
x0yH6edWE60EKeZEO9/hJu5cXAhmvJXal9tmOtGR8hj5XeB8GHpnlSO9F2/TzoTjxoN8mDZk9sf6
ga6/3+S+Y4YxH5/KMvSbi3VD11/BzVyYxg9D6w2/ZfgaxR2hyYZhr2KaBp4wwAtj+Bj6j2uCnujU
dLsoBvJ1dwSeVvkxxnx8fP7AMO1QUIOf6I9RWS8bBtA/niDZVX8/I6afW41ieBs+sHutNEtj+IsN
IgeCKSYq6+XCwA4DAIo+6e/GnHUMHMMAvirGBEKKiUo0mTA8ZJ7aPVuCwIyYfm41huFN+MBvRRZ9
Mi4Thr/WEHYfJfYvtsthAP2D3SOoXS36onY3BgRgupChKwGOyXvXOAMDiLN0ITM7xmeixyutoT9h
Ep+C82DYS6xCEBKYmKyXEcPaE0ESf92VE2MeknZj8LAiO2gSm/X8MSNzKzFK9mvNh2mmMXBYkR0N
jU3BWTCA/sHHsP7r7DFZLwdmSHni6+yxKdiJMWadbsyQ8ugTdztMRKLxx7jnVnBYDy2OAYT0IcNl
zUyY6VmnHDJw+MZVRNbLgJFCRtwWMjYFZ8CwhulTXkrWc2LOOga6MGBYDS2N4d/u/49uHYaJTMGT
mMmJHvuKFfmqryRAolNwOobGEsYPnWtZDFu+bjpXStZzYoCOAcRe2PK3g2tJDE953wyrMFEzD2Zq
oseaBr8fXAkpOBnDKgKxp4ujxTFs8VtmYq6UrOfC+E6BlYnV0hh1lOxXjEvBqRjeNI28BiCxWW8S
04xjWG30o+SyGHViNVRWXNZzYTzn42bIFMHY51bKjoGEiUvBiRg4rGPedyA4601hJmadYFgHLo0x
Ux5JyXouzNkLYwuZEpi+FeTCFzYqNj4Fp2HAsApUl0ZlvSnM6KzTGjLLYrSQSch6Lkz3QUcx+uGz
YhipGZStaqNkv7hZBKOOkj2MYkKz3hRmdNYJBoz88oIYI37js54D43VImguavjKKYWzTGbbMSHkJ
KTgZY4ZMfNZLxpghMx+mmcKwFbQhHZK4rJeM6bc+H8Zr1jlggImJScFZMHq1xWa9FExfIfqLM2HG
Z50uTGzWy4KB82LOOkbfnrIQaMtjU3AOjNntAYnKekkYpPw1O2b8KDB2vQZIVNZLwohgAcZymBXT
vf8Ehi113K0iIgX7YsxPT0t/fN62nGLCsl4ahl5sYPuWxiIYWiu2K8v7c4NhiWYCM3VI+lhVtlci
U7AdE3KJiK1EpuBxDHgA0rsHFEBist44Br6XP+rCGPTnBEx41hvH4FfTGGx7EWbEBFwiQoanwWuY
8BQ8julrZuzyWwjNZXFZbxyD3nhgECiDgT94YGxNGJeCxzHfdskutGbiUrAdcxbv6XXJti1m4lKw
J8ayvb7YelNc1kvHWPPMUhh7ASQi641jvK6SthaYDwOyYIJTsCcG6BubKlFZ7/PBhGa9uTBRKXgc
EzkFJpEp2IpJnY93/yI06/lhQmedl4gJzXqzYWB2TJOGCb13vBUTNB93FHZhI713fEDW88OMf2vR
iWH3jr8YDN0hDUg0s2FYy/45I8bvW4sjmD9lwJwzYFii+Yb+sc2MgXEY/AQvB4NOtEr9E818GEiC
U/C8mMBZsBUDxPvFz8dJ1MTTDwOMTf0SMWETz/kwEbPgi8fkmAKTmImnFyZiOnOJmLCsNyMG/vow
OabAJCbreWFipjOXiAlKNDNiwrPexWPO4t2SpsAkIuv98jAwHhOUaObEwCvGUYKzng0DxJslzcdn
wwBjO/6YkEQzJyY46302mOCsZ8Fkmo/PhImbW5HwFDwrBl4xjhKa9SyYTPPxmTCR05nwFDwrJjTr
fT6Y0KxnwZwvEZM6tyLBKXheDLxiHCUw61kw4BIxyXOr4BQ8LyYw631GmMCsZ2L66cxFYZLn4yQ0
BXtgoudWJDTrfU6YsKxnYvrpzEVhmlwY70TjgYmfW4Vmvc8JE5b1Lhxzzo7xTjRuTIa5FQnMer80
zMRDQ6Yx3lnPAzP+aKKJEpSCTUy36eHhRLtUjG+icWO8H040WoKynhdm9BFopTH0GTspGN+s54dJ
iGGQgjHn47TExzDF+CYaN0Z98GMdi4EzYI7ggjDReZhifLOeN4Y9NzCihKRgA2PMx7sSmWxCUrA/
JjKGQ7KeG9PobxsXwzNh4mI4JAWHYOJiGMyDiYthivFMNEGYqAETJmDO4j1OtjeOGTBnw8TEMMV4
Zj03prG9c0QMB6RgJ0Z/3Lgo4TEckILdmNO99b2DYzgg67kx+gPHu/cGi2DIa+ubh076AlKwO8+4
Yjh4wARZMK4YBuEYv0QzinHEcGCygXkweWI4AfOivFGOGKYYv6w3gckRw/4peAJD/mJ9/6AY7jGT
ica9eytKegz7Z71JzGNj3UBdBnPW3it5wPRPwdOY9BgG8ZiP+nslx3CPmUo0I+eb+pIaw5B4Zj0f
TGoMcwxE+x//PxSjdyeSHMMUQxqENz9OPMR+7GKeviRO+njWwxj8bhuMMSI4dcAUKXh9OIxbRi8a
lIp9wPSMYZ71jlVbvsiBSdpxoXeowe9Xbc3scAvahmAsEZwWw5jevefv2pgBgIbZzskZu7peLkkx
DAisntreBGseZrsAjCWC02IYkKp+avMMWosws94zxPE1NOsWEiZ9sMKApWDY6e2BbP1S5wfbO8YP
mLhqRzKBEVWDt94YW3+KHzDxCtJ7YdHPgvrrB6yPs7ff8sX+ceMGTLxqDQB1mO4hOf6YZ+vbOgZM
MGUhiGaaDgP58i+9MY6qsSeb0RimFvoEZTHxHDC2XQUH5tn6ccNjmFlUjDhnb2snB8beoYJjGK8G
7pPAdFfAbP0xL/aPGxbDxy5BA4Hpn2pHrNM+FyYshu3yY7cYKxjIF1qCxokJimHrgNlb+JN5u6zX
3/w5BOOIYXtDWeSDhd/+r8d0V51sAzCOGLYPmGYMS5Z2Lk7/bDSMGTQjGEcM+036ZIu4F2EjIF13
CsI4Ythr0qdYNEzXncwIHsN8sk+dHMnGbeE3RkQPKAljn9g4ko0k3ykWgcEPUDQRFIvDMJ9+tm52
atK30z4D4gZ6m54UjCPZjE/6dAttG7qI3sBIznpm357AhMSwSDaGhW6cLutTsDPRTGDCY9i0UEz7
f/40Txlj9O0pTFgMQ5ulw3wLyETWm8K4YrixLcVrm0VgMHmVjPEeMEH7v93Gti5k20fkjcB0KdhI
NNMYzwETwE3bRtYQg9Kx4ESM54AJj2hX2e/XDqXDr/LgFIPxm/Sh465q91vpPpK+JlAxGON4jNek
D+Cbmm1nbX5NocPQRIMQQRvXnNwH4xPDEFeQfm6wsz++g/53d8d2oeABpmA8Yhgd94hGB2x3CKAd
c0c53xMAuplYHGY6hgFe7UWV7I124pg7/m/a6unqLhIzOemDuN4IxK3RTnQ5vBM1SNDd92k1Mzlg
onY6xTdhCWH66123IjmQPUzDTAyYEO+7HI9IrVdNu+274WUA1km96dPUgCkJIFnpV8DDtl66ZRCT
A8KJmPFJH8Z13zb4CHXM3TA4tnstqPs5KunxUls1IobXQ20grLcTjZduESVnwIwcJcFESnVtx1Lb
6U4ej+ibdDWXgBk7StKO1gMVdb2FzSpOd/L+iTwhT8KMxPDhRloA+33dNlpPr5WH5GTDjEz6jkCC
ggMQm0OIWjiGN528E5eGcQ6Yw+ZZ6Wn47eu+OnjQ1DImYtopryx9/qGc7qF6EKJvtBPva4OD/5QH
4xowh5DlGxPp+vRvYjHbOt2RWQ02ErHfpBbHgPlHpTNjsW95et2lN14VK1xJFZWOcU36XqmPDV1h
ZqG9iRUoFvPfOnjwvrZRbAMmxv+g/n6LeLwAUSdQeTkfxpps1l8rs3O0r7vYVTcv11Pw8RlbscUw
vFF2XOCxflQOVKhjVfdxMmBsMbwGQN34o7YfA+QXux/CjunZixnDCCP1KIluUYLG3ZkiMGYMY3oI
TzpK8vhHqK2BLD8HHZR2FjOGVy1m2MN8vN/ocz05aOqsGHPArOjGuxh+vMfEOBgx+HtX0LmDkVKr
W8J8UvuaHdVk8WLUHex/6ist5KzKWNEGTLRjWzg1AInYNTDDUeL+g2wzYbRkg9d8C3+BUPQjreqk
JcMTYW0fMgqjJpsOQ77//b3eKn3tib/7cwwB5yinipJsRDNJ+cXEiEPWw5HrgLO3k0Wpmu5j/9Rt
ysSIaUVfMQHntaeLEsPdsfG3HUKhilIpFWO96DQWo8TwWmzj266KbBhS1XhI3rZWisdIMYwRrxFM
uoenWTHkWPUY+xU00RgphlG/99x0VWWz4C8+vVQVm3oet5kx0oDZZ9UxDBbXzNDrwKyNlIQZBsw+
vzZdu7ktYyUBMwyYHhgfSxKmTzZ4EuNlScM8+2L8LGmYLob7XCa+e4lwlCURI2K43++3Y3wtiRgR
w/1hByvG25KK4TGMD2ozQRxlScbwAXPlxgRYkjF8wHRjQizpGDZgrhUMAv3DO4Ms6RiabHC3a8Jv
UoABBDGWDJg2htEGqBjRuwItOTDPbUXUMgYd+L5KqCUHpo1hqNQMRAwTbMmCeam7B7wKDKuZcEsW
zKdniGRMGzIwxpIH82klhkqGwZhAGGPJhPlfMVKya/HoqetDjCUT5iz2KRmmjoqXjBhyAzrMkR7x
DXqsdmbMR3Lc04sgKAbSo8/LYki1RpvjCbfpl154uzAGV5jUXyOyZxcMLowhuzWo38LjLRsZgh44
PgOGrA7oa1DxUWpxzG273/oHMWIujcH4sFo35DIw7VBdw1cXgKFfboEY1us3F4Jp95aO+IdLwdBy
CTFzmZj+lqxXzBUzUcAV80vCPF0iJuRJ7J8FBrKHIy+NOXMCegKXg8F/vYRmEhjyzSVh3l4S5usL
wuDTBWHQ6YJ60/B1jCUxxg0Trpgr5peE0e8ksejk6opxFqBiltzXvmLc5axiljwOfGEYLev90yVh
toti1EQTl2Z+nRi1b8f17HwYpTvFdaZfKUbpTtuFMXIER8ZvPowcwZHxmxEjXZPruHSzIOYluZUy
YoZ2im2lnJgPqa2UE9NdknuMfoeMmK5qoismK4ZXTXzFZMV8+nlFiOuSbJ+SFUMvWE/553kxieWK
cZUrxlWuGFe5YlzlinGV578Bev0j6cIbqrAAAAAASUVORK5CYII=
--Multipart=_Tue__10_Oct_2006_19_40_47_+1300_KR6QajtdOtIE+RE_--
|
|
Tue, Nov 21 2006
21:30:19
|
|
Mail sent by msieczka
|
|
Hamish (and All),
I have revisited this bug and I think I know why you, after your fixes, were
able to produce correct buffers using my 'ditches' vector, while I was still
obtaining errors (though somewhat different than at the beginning, before your
fixes).
step-by-step:
1. unpack the bzipped testing location I have sent you
2. enter the location - don't touch anything yet!
3. v.buffer input=ditches output=buf1 type=area buffer=1
4. display 'buf1'; you should see the wrong buffer around the parcel that has
cat 1205 in the 'ditches' vector - as I did
5. now, open 'ditches' in v.digit, pan to where cat 1205 is and disjoin it's
boundary, and the snap the vertiices back as they were originally
6. v.buffer input=ditches output=buf1_new type=area buffer=1
'buf1_new' is OK! - although the command in point 3. and 5. is identical, and
although the input data haven't changed a bit - only one vertex was moved, but
snapped back to it's original position immadietly.
I have no idea why it is like that. Hamish, can you reproduce that? Does this
explain how the same data worked for you but not for me?
Strange. The input vector in both cases is virtually the same, in both it is
topologicall, error free (according to v.build, v.clean and visuall inspection
in v.digit). But somehow, moving one vertex slightly and snapping it back
"fixes" the vector so that v.buffer can handle it OK.
'ditches' was hand digitised by me in QGIS 0.74, few months ago.
Maciek
|
|
Thu, Nov 23 2006
00:14:59
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 23 Nov 2006 11:59:50 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20061123115950.0bfdd835.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061121203019.3CBC91006CE@lists.intevation.de>
|
References |
<20061121203019.3CBC91006CE@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 |
|
Maciek Sieczka via RT wrote:
>
> I have revisited this bug and I think I know why you, after your
> fixes, were able to produce correct buffers using my 'ditches' vector,
> while I was still obtaining errors (though somewhat different than at
> the beginning, before your fixes).
>
> step-by-step:
>
> 1. unpack the bzipped testing location I have sent you
>
> 2. enter the location - don't touch anything yet!
>
> 3. v.buffer input=ditches output=buf1 type=area buffer=1
>
> 4. display 'buf1'; you should see the wrong buffer around the parcel
> that has cat 1205 in the 'ditches' vector - as I did
Nope, I still get correct output the first time.
g.region ditches_buf
d.vect buf1
d.vect ditches col=blue cats=1205
d.vect ditches col=red cats=1203
d.vect ditches col=yellow cats=1204
maybe it has to do with the 1203,1204 ?
can you isolate the problem with:
g.region ditches_buf
v.in.region problem_box
v.select ain=ditches bin=problem_box out=problem_areas
v.out.ascii format=standard in=problem_areas
v.in.ascii
v.buffer
?
e.g. is there a single boundary line between 1203,1204 or two (slightly
not touching) boundary lines? "v.clean tool=rmdupl"
> 5. now, open 'ditches' in v.digit, pan to where cat 1205 is and
> disjoin it's boundary, and the snap the vertiices back as they were
> originally
>
> 6. v.buffer input=ditches output=buf1_new type=area buffer=1
>
> 'buf1_new' is OK! - although the command in point 3. and 5. is
> identical, and although the input data haven't changed a bit - only
> one vertex was moved, but snapped back to it's original position
> immadietly.
>
> I have no idea why it is like that. Hamish, can you reproduce that?
no..
> Does this explain how the same data worked for you but not for me?
>
> Strange. The input vector in both cases is virtually the same, in both
> it is topologicall, error free (according to v.build, v.clean and
> visuall inspection in v.digit). But somehow, moving one vertex
> slightly and snapping it back "fixes" the vector so that v.buffer can
> handle it OK.
>
> 'ditches' was hand digitised by me in QGIS 0.74, few months ago.
maybe it is a FP epsilon problem, which is slightly different machine to
machine + compiler to compiler? e.g. 123.4000000000002 vs 123.4.
You mention no errors with these, but did you try running v.buffer with
the output of v.build and v.clean or just see there was no error reported?
does the error survive v.out.ascii form=standard + v.in.ascii form=standard?
I see in the buffering output there are 7 areas without centroids, but I
wonder if these are just "islands" (holes) within areas?
Hamish
|
|
Fri, Nov 24 2006
03:39:17
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 24 Nov 2006 15:39:05 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciej Sieczka <tutey@o2.pl>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20061124153905.202a8544.hamish_nospam@yahoo.com>
|
In-Reply-To |
<456611DF.90003@o2.pl>
|
References |
<20061121203019.3CBC91006CE@lists.intevation.de> <20061123115950.0bfdd835.hamish_nospam@yahoo.com> <456611DF.90003@o2.pl>
|
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 |
|
Maciej Sieczka wrote:
> > g.region ditches_buf
>
> Which one is that? It's not there in the package I sent you.
It is the saved region:
$ cat vbuffer_bugs/vbuffer_bugs/windows/ditches_buf
proj: 1
zone: 33
north: 5678240
south: 5677910
east: 600860
west: 600570
cols: 29
rows: 33
e-w resol: 10
n-s resol: 10
top: 1
bottom: 0
cols3: 33
rows3: 31
depths: 1
e-w resol3: 8.78787879
n-s resol3: 10.64516129
t-b resol: 1
> > can you isolate the problem with:
..
> > v.select ain=ditches bin=problem_box out=problem_areas
> > v.out.ascii format=standard in=problem_areas
..
> Done that before, to no avail.
clearer: if you can extract it to a few simple areas & export with
v.out.ascii it is easier to follow step by step in the debugger. Also
you can post that to the bug's history and others can try without
needing you to send them the 1mb location download- more data points.
> >> 'ditches' was hand digitised by me in QGIS 0.74, few months ago.
>
> > maybe it is a FP epsilon problem, which is slightly different
> > machine to machine + compiler to compiler? e.g. 123.4000000000002 vs
> > 123.4.
>
> Would that mean v.buffer is supposed to work on some Linuces and not
> on the other? That would be a nightmare.
I don't know. It is just a guess of why our two systems would be
different. I am testing with a Pent4 32bit debian/stable machine.
Is yours 64bit? v.buffer will try and do the same calculation, but the
computer may give a slightly different results. That will happen with
any 32bit and 64bit system doing FP math, with any program. It would be
a v.buffer bug if e.g. if it tests FP1==FP2 when it should test
"fabs(FP2-FP1) <= EPSILON"
> The point might propably be about the boundaries of the problematic
> area being recognized as snapped on your machine, while being
> recognized as disjointed on my machine. That'd be nuts tough.
does "d.what.vect -f" (or without -f check area size) show the original
as a closed area?
> Please watch the swf at [3], where I present step-by-step the two runs
> of v.buffer on the problematic dataset - before and after the required
> "edit", including how the "edit" looks like. I'm just moving vertex of
> a topologically clean boundary a bit and snapping it back. Strange...
sorry, I don't have flash installed. But I trust you are honest and we
have tried the same commands :)
Hamish
|
|
Sun, Nov 26 2006
22:38:08
|
|
Mail sent by msieczka
|
|
hamish_nospam@yahoo.com wrote (Fri, Nov 24 2006 03:39:17):
> Maciej Sieczka wrote:
>>> g.region ditches_buf
>> Which one is that? It's not there in the package I sent you.
> It is the saved region:
Oh, right. Sorry, my bad. I thought you meant some vector map (I missed the
fact you didn't put "vect=" into your g.region call).
>>> can you isolate the problem with:
...
> clearer: if you can extract it to a few simple areas & export with
> v.out.ascii it is easier to follow step by step in the debugger. Also
> you can post that to the bug's history and others can try without
> needing you to send them the 1mb location download- more data points.
You are right, should have thought of using v.out.ascii for debugging.
>>> maybe it is a FP epsilon problem, which is slightly different
>>> machine to machine + compiler to compiler? e.g. 123.4000000000002 vs
>>> 123.4.
>> Would that mean v.buffer is supposed to work on some Linuces and not
>> on the other? That would be a nightmare.
> I don't know. It is just a guess of why our two systems would be
> different. I am testing with a Pent4 32bit debian/stable machine.
> Is yours 64bit?
No. 32 bit, Pentium M 750 (Dothan). Ubuntu Dapper 2.6.15-27-686. I'm not using
any optimization at the build time. GCC 4.0.3-1ubuntu5.
> v.buffer will try and do the same calculation, but the
> computer may give a slightly different results. That will happen with
> any 32bit and 64bit system doing FP math, with any program. It would be
> a v.buffer bug if e.g. if it tests FP1==FP2 when it should test
> "fabs(FP2-FP1) <= EPSILON"
This is propably not the case here. But I have a lead :). Please read at the
bottom.
> does "d.what.vect -f" (or without -f check area size) show the original
> as a closed area?
Yes:
$ d.vect ditches; d.what.vect -f
map: 'ditches'
mapset: 'vbuffer_bugs'
feature type: Area
area size: 475.449658
Layer: 1
category: 1205
Database connection not defined
>> Please watch the swf at [3], where I present step-by-step the two runs
>> of v.buffer on the problematic dataset - before and after the required
>> "edit", including how the "edit" looks like. I'm just moving vertex of
>> a topologically clean boundary a bit and snapping it back. Strange...
> sorry, I don't have flash installed. But I trust you are honest and we
> have tried the same commands :)
Following your v.out.ascii hint here's what I found out.
Extract the problematic area 1205:
$ v.extract in=ditches out=ditch_1205 type=area list=1205
Buffer it:
$ v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
$ v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
As expected, both outputs are wrong, see [2] and [3], respectively.
Running the ditch_1205 through ascii vector, like:
$ v.out.ascii ditch_1205 form=standard | v.in.ascii format=standard
out=ditch_1205_asciied
doesn't change anything - buffering the ditch_1205_asciied still yields wrong
results, exactly the same as seen on [2] and [3].
However, after "editing" the ditch_1205 in v.digit, like shown on [4],[5],[6],
ie. dissjoining the boundary and snapping the vertex back,
$ g.copy vect=ditch_1205,ditch_1205_edt
$ v.digit ditch_1205_edt #see [4],[5],[6]
buffering this resulting vector yields correct results; see [7],[8], respectively:
$ v.buffer ditch_1205_edt out=ditch_1205_edt_b1 type=area buffer=1
$ v.buffer ditch_1205_edt out=ditch_1205_edt_b4 type=area buffer=4
Now, why does this "touch" of v.digit help? The *only* difference between
ditch_1205 and the "edited" ditch_1205_edt according to v.out.ascii is where
the boundary no #4 is mentioned, see:
$ v.out.ascii ditch_1205 form=standard | awk 'NR>10'
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
compared to:
$ v.out.ascii ditch_1205_edt form=standard | awk 'NR>10'
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
Note there is no single difference between the 2 *besides* the order in which
boundaries are listed. Somehow, the ditch_1205 having boundary #4 listed as
first is wrong for v.buffer (on my machine), while the ditch_1205_edt, having
the same boundary listed as the last one, is OK.
Does this finding help?
Maciek
[0]http://kufaya.googlepages.com/v.bufferbug%232765
[1]http://kufaya.googlepages.com/ditch_1205.png
[2]http://kufaya.googlepages.com/ditch_1205_b1.png
[3]http://kufaya.googlepages.com/ditch_1205_b4.png
[4]http://kufaya.googlepages.com/ditch_1205_edt1.png
[5]http://kufaya.googlepages.com/ditch_1205_edt2.png
[6]http://kufaya.googlepages.com/ditch_1205_edt3.png
[7]http://kufaya.googlepages.com/ditch_1205_edt_b1.png
[8]http://kufaya.googlepages.com/ditch_1205_edt_b4.png
|
|
Mon, Nov 27 2006
02:56:42
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 27 Nov 2006 14:56:36 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20061127145636.2cd38413.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061126213808.85D3E1005C1@lists.intevation.de>
|
References |
<20061126213808.85D3E1005C1@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 |
|
Maciek Sieczka via RT wrote:
>
> Note there is no single difference between the 2 *besides* the order
> in which boundaries are listed. Somehow, the ditch_1205 having
> boundary #4 listed as first is wrong for v.buffer (on my machine),
> while the ditch_1205_edt, having the same boundary listed as the last
> one, is OK.
>
> Does this finding help?
Yes. It is excellent information. (but no solution yet)
another test:
v.build.polylines in=ditch_1205 out=ditch_1205_single
v.buffer ditch_1205_single out=ditch_1205_single_b4 type=area buffer=4
Could others try buffering this area? Maybe it fails for someone else?
GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
EOF
# and then:
GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
?
Hamish
|
|
Mon, Nov 27 2006
08:24:51
|
|
Mail sent by tlaronde@polynum.com
|
|
Return-Path |
<tlaronde@polynum.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
tlaronde@polynum.com
|
Date |
Mon, 27 Nov 2006 08:27:38 +0100
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it, hamish_nospam@yahoo.com
|
Subject |
Re: [GRASS-dev] [bug #2765] (grass) v.buffer produces strange results
|
Message-ID |
<20061127072738.GA237@polynum.com>
|
References |
<20061126213808.85D3E1005C1@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20061126213808.85D3E1005C1@lists.intevation.de>
|
User-Agent |
Mutt/1.4.2.1i
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-4.993 tagged_above=-999 required=3 tests=[BAYES_00=-5, NO_REAL_NAME=0.007]
|
X-Spam-Level |
|
On Sun, Nov 26, 2006 at 10:38:08PM +0100, Maciek Sieczka via RT wrote:
>
> $ v.out.ascii ditch_1205 form=standard | awk 'NR>10'
> B 4
> 600727.68682251 5677973.32091602
> 600739.16582305 5678137.49568095
> 600736.32863997 5678140.4618269
> 600730.63832718 5678056.67823368
> B 2
> 600730.63832718 5678056.67823368
> 600725.02385533 5677974.01131491
> C 1 1
> 600730.04890192 5678035.56666655
> 1 1205
> B 2
> 600727.68682251 5677973.32091602
> 600725.02385533 5677974.01131491
>
> compared to:
>
> $ v.out.ascii ditch_1205_edt form=standard | awk 'NR>10'
> B 2
> 600730.63832718 5678056.67823368
> 600725.02385533 5677974.01131491
> C 1 1
> 600730.04890192 5678035.56666655
> 1 1205
> B 2
> 600727.68682251 5677973.32091602
> 600725.02385533 5677974.01131491
> B 4
> 600727.68682251 5677973.32091602
> 600739.16582305 5678137.49568095
> 600736.32863997 5678140.4618269
> 600730.63832718 5678056.67823368
>
> Note there is no single difference between the 2 *besides* the order in which
> boundaries are listed. Somehow, the ditch_1205 having boundary #4 listed as
> first is wrong for v.buffer (on my machine), while the ditch_1205_edt, having
> the same boundary listed as the last one, is OK.
FWIW, it seems clear that the problem is a snapping one, that is that a
node, whose coordinates appear to be the very same as a previous node
entered is _not_ snapped and is created as a new node. Hence even if
visually the area edges are connected, they are not since they end with
distinct nodes (that are equal but not identical).
I suspect that the offending node is:
600727.68682251 5677973.32091602
I imagine that with the new vector engine you still have a '-s' option
to v.support(1) or equivalent.
Take the non working case, and before buffering snap nodes with a very
small threshold. The problem shall disappear (this is indeed what you do
in v.digit(1), except that for v.digit(1) the snapping threshold is
usually relatively high).
If the diagnostic is correct, one thing to look in your code is the
handling of the 'C' record, I imagine this is the centroid?
I guess that centroid are not snapped, so that the code disallow
snapping when entering a centroid and that this is still in effect with
the next coordinates entered.
Hence, when the 'C' record is---first example, non working---before a
coordinate that is already a node, it is not snapped.
In the second example, since the next coordinate is not already a node
(it is a creation), no snapping is done but this is no harm.
You can confirm by moving the 'C' record in the first example last. It
should then work.
If people that can't reproduce the bug are snapping node before trying,
the difference is understandable.
If they are not snapping nodes before trying, what is to be checked is
is the floating point support linked to the hardware type (FPU, ieee754
support or not etc.).
HTH
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
|
|
Mon, Nov 27 2006
20:56:04
|
|
Mail sent by msieczka
|
|
tlaronde@polynum.com wrote (Mon, Nov 27 2006 08:24:51):
Thierry (CCing Hamish),
Thanks for trying to help but your analysis is mostly worng. Please read below.
> FWIW, it seems clear that the problem is a snapping one, that is that a
> node, whose coordinates appear to be the very same as a previous node
> entered is _not_ snapped and is created as a new node.
But yes *it is snapped*. Otherwise the boundary would not be closed, and there
would be no area - while there is:
$ v.info -t ditch_1205
nodes=4
points=0
lines=0
boundaries=3
centroids=1
areas=1
islands=1
faces=0
kernels=0
primitives=4
map3d=0
And the bug is that this topological area is not buffered properly, unless I
disjoin it's boundary and join it back.
> Hence even if visually the area edges are connected, they are not
But yes *they are connected*; the picture [4] shows that (ditch_1205 in
v.digit, before any edit). The picture [5] shows what the colors in v.digit
would be if the boundaries would be not connected.
> since they end with distinct nodes (that are equal but not identical).
>
> I suspect that the offending node is:
> 600727.68682251 5677973.32091602
In what sense? All nodes coordinates are identical in vectors ditch_1205 and
ditch_1205_edt (see my previous message to learn how they were created). Only
the sequence of of boundaries is different between the 2 vectors.
> I imagine that with the new vector engine you still have a '-s' option
> to v.support(1) or equivalent.
v.clean tool=snap
> Take the non working case, and before buffering snap nodes with a very
> small threshold. The problem shall disappear (this is indeed what you do
> in v.digit(1), except that for v.digit(1) the snapping threshold is
> usually relatively high).
Wrong. It doesn't help, and doesn't change anything in the data. And that's as
expected, because all nodes are already snapped in the problematic vector
ditch_1205, like I wrote above.
[4]http://kufaya.googlepages.com/ditch_1205_edt1.png
[5]http://kufaya.googlepages.com/ditch_1205_edt2.png
Maciek
|
|
Mon, Nov 27 2006
21:26:26
|
|
Mail sent by msieczka
|
|
hamish_nospam@yahoo.com wrote (Mon, Nov 27 2006 02:56:42):
> another test:
> v.build.polylines in=ditch_1205 out=ditch_1205_single
> v.buffer ditch_1205_single out=ditch_1205_single_b4 type=area buffer=4
The ditch_1205_single_b4 is an empty vector for me (0 features). Even taking
the #4249 bug into consideration and aplying the 'v.clean tool=prune thresh=0'
workaround on ditch_1205_single_b4, and buffering it's result, the v.buffer
output is still empty (BTW - strange, I couldn't reproduce bug #4247 with
ditch* data; I need to look into this tomorrow).
How does it work for you?
> Could others try buffering this area? Maybe it fails for someone else?
Please please.
Maciek
|
|
Mon, Nov 27 2006
21:52:06
|
|
Mail sent by tlaronde@polynum.com
|
|
Return-Path |
<tlaronde@polynum.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 27 Nov 2006 21:55:01 +0100
|
From |
tlaronde@polynum.com
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Subject |
Re: [GRASS-dev] [bug #2765] (grass) v.buffer produces strange results
|
Message-ID |
<20061127205501.GA6196@polynum.com>
|
References |
<20061127195604.B27711005B6@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20061127195604.B27711005B6@lists.intevation.de>
|
User-Agent |
Mutt/1.4.2.1i
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-4.993 tagged_above=-999 required=3 tests=[BAYES_00=-5, NO_REAL_NAME=0.007]
|
X-Spam-Level |
|
On Mon, Nov 27, 2006 at 08:56:04PM +0100, Maciek Sieczka via RT wrote:
> tlaronde@polynum.com wrote (Mon, Nov 27 2006 08:24:51):
>
> Thierry (CCing Hamish),
>
> Thanks for trying to help but your analysis is mostly worng. Please read below.
OK, that was what I tried to deduce from the data (but not knowing GRASS
6.x). So just drop :)
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
|
|
Tue, Nov 28 2006
13:33:10
|
|
Mail sent by msieczka
|
|
msieczka wrote (Mon, Nov 27 2006 21:26:26):
> hamish_nospam@yahoo.com wrote (Mon, Nov 27 2006 02:56:42):
>> another test:
>> v.build.polylines in=ditch_1205 out=ditch_1205_single
>> v.buffer ditch_1205_single out=ditch_1205_single_b4 type=area buffer=4
> The ditch_1205_single_b4 is an empty vector for me (0 features).
Sorted out. This happens because v.build.polylines removes categories from
centroids, while v.buffer works only on features that have cats.
(This is another bug in v,build.polylines, or bad feature at least - why
should it remove the cats from centroids?).
Once I add the category to the centroid back, by
$ v.category in=ditch_1205_single type=centroid option=add
out=ditch_1205_single_addcat
the output of
$ v.buffer ditch_1205_single_addcat out=ditch_1205_single_addcat_b4 type=area
buffer=4
is OK! (visually, at least; but there are 8 redundant nodes in it!)
> Even taking the #4249 bug into consideration and aplying the 'v.clean
> tool=prune thresh=0' workaround on ditch_1205_single_b4, and buffering it's
> result, the v.buffer output is still empty
This step is not required; IOTW, the buffer is OK in spite of bug #4249, which
causes that the ditch_1205_single, and its's "child" ditch_1205_single_addcat
have doubled vertices on the boundary; but this doesn't mean the bug #4249 is
gone :), only it doesn't do harm in this case.
> (BTW - strange, I couldn't reproduce bug #4247 with ditch* data; I need to
> look into this tomorrow).
Sorted out. For the bug #4247 to crop out, the input boundary has to be a
polyline already (ie. v.build.polylines corrupts only boundary polylines). See
my recent notes on http://intevation.de/rt/webrt?serial_num=4247.
So, how does that look now to you? (if bugs in v.build.polylines where fixed
we could avoid some cofussion).
Maciek
|
|
Sun, Apr 29 2007
10:53:15
|
|
Comments added by hbowman
|
|
Hi,
I have now upgraded a machine to Debian/Etch, and I can now reproduce this bug
there.
stay tuned...
Hamish
|
|
Sun, Apr 29 2007
14:18:20
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 30 Apr 2007 00:18:07 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [bug #2765] (grass) v.buffer produces strange results
|
Message-Id |
<20070430001807.1866891b.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20061128123310.6E59A1006C2@lists.intevation.de>
|
References |
<20061128123310.6E59A1006C2@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, score=-3.151 tagged_above=-999 required=3.5 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=1.849]
|
X-Spam-Score |
-3.151
|
X-Spam-Level |
|
Hi,
WRT bug #2765, v.buffer errors--
https://intevation.de/rt/webrt?display=History&serial_num=2765
example of vector shape that doesn't get buffered correctly:
GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
EOF
# and then:
GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
I now have a machine where it fails for me, so some more debug info
to share:
The problem is in lib/vector/Vlib/buffer.c clean_parallel()
(no big surprise there)
Vect_line_buffer() calls Vect_line_parallel() for side 1,
Vect_line_parallel() calls parallel_line() then clean_parallel(),
clean_parallel() creates a centroid in the buffered area, then tests to
see if the new centroid is in the ORIGINAL (smaller) area. In some
cases, the centroid will be within the buffered area, but outside the
original area.
here's a picture and zoom:
http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765.png
http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765_zoom.png
since the point is outside the area, that section of the buffer is
thrown away and we get a bad result.
[in point_in_buf() (sd=15.140885 <= d=16.000000) so it returns 1]
actually the erring function is not called point_in_polygon(), it is
called point_in_buf():
/* is loop in buffer ? */
if ( point_in_buf( origPoints, px, py, d ) ){
but it is testing vs. origPoints (original shape to be buffered) not
the to-be-cleaned buffer area ??? so not doing "point_in_buf" at all.
I am not sure how to fix that.
see also the note by me in the bug report dated Tue, Oct 10 2006.
other notes:
* v.build.polylines on the original shape fixes it (this time)
* buffer distance in the cleaning step when using bufcol= param is
also buggy. (only uses the last buffer size value loaded)
Hamish
|
|
Sun, Apr 29 2007
14:27:52
|
|
Comments added by hbowman
|
|
MIME encoded image posted to the bug report on Tue, Oct 10 2006 is reproduced
here:
http://bambi.otago.ac.nz/hamish/grass/bugs/vbuff_fill_bug.png
Hamish
|
|