I think that would be OK. If you send the patch to the list I'll commit it to trunk and the 6.3 release branch.
--Wolf On 16.12.2007 13:16, Daniel Bundala wrote: > Dylan, > > I was thinking about the problem last night and a solution I have come > up with is the following. > > As I mentioned in my previous post, a solution is to translate the > corresponding points little bit. I do not know how good this technique > is, but we can use it "approximate" the tangent at the point in > between. My reasoning is: Take two points p1, p2 which are L metres > apart. And we send p1 to p2 (or vice verse), i.e. L goes to 0 and take > the limit. Then we get (according to the calculation I do in > v.generalize) that the tangent is zero. > > I think that this behaviour is consistent with the other possible > situations and shapes of lines. Especially, it would be better if the > algorithm does something "reasonable" which imitates the situations if > the points are close to each other. > > If no-one is against this, I will add that one line to the code... > > Daniel > > On Dec 15, 2007 8:36 PM, Dylan Beaudette <[EMAIL PROTECTED]> wrote: >> On Saturday 15 December 2007 05:38:44 am Daniel Bundala wrote: >>> Hello, >>> >>> I am not 100% certain as I did not test it, but I think that the >>> problem is that the very last line in myvect map contains 2 points at >>> the exactly same position (131.5, 67.5). Actually, you are so lucky to >>> get this (faulty?) behaviour:) because this occurs only if there is >>> exactly one point in between them. In your case, 2nd and 4th points >>> have the same position whereas 3rd is at a different position. >>> >>> Possible solutions are: >>> -Firstly, is your map correct? I mean, does it make a sense to you >>> that one of your lines is of this strange shape? >>> -If yes, then I believe that the behaviour of the algorithm is >>> undefined. Because Hermitian interpolation needs to have some "notion" >>> of a tangent at each point. And I really don't know what can be a good >>> choice of a tangent at points like your 3rd point on the last line. >>> -So you can either use different smoothing algorithm (Chaiken?) or >>> shuffle the second and fourth point little bit so that they do not >>> coincide. In other words, translate the second point to 131.5000001 >>> 67.500001 and fourth point to 131.49999999 67.499999 say. In the later >>> case, I doubt that the output of v.generalize will be particularly >>> nice...... >>> >>> Hope this helps, >>> Daniel >> >> Daniel / others: >> >> how about doing a first pass to check for points / segments where the >> requested interpolator is undefined ? That way an appropriate warning could >> be issued along with suggestions like you have presented. >> >> I suppose that a moving window on the vertices could accomplish this, >> checking >> for the conditions above. >> >> What do you think? >> >> Cheers, >> >> Dylan >> >> >>> On Dec 14, 2007 4:41 PM, Andre Hauptfleisch <[EMAIL PROTECTED]> wrote: >>>> I've attached the myvect and myvect_smooth files. >>>> >>>> Thanks for the help!! >>>> >>>> >>>> >>>> >>>> On Dec 14, 2007 4:53 PM, Moritz Lennert <[EMAIL PROTECTED] > >>>> >>>> wrote: >>>>> On 14/12/07 15:37, Andre Hauptfleisch wrote: >>>>>> I'll try to upload the vector layer I used to an ftp site. What would >>>>>> the best output format be? DXF? >>>>> You can just use the output of v.out.ascii. If the file is not too >>>>> large, you can zip the output and send it to me directly. >>>>> >>>>> Moritz >>>>> >>>>>> On Dec 14, 2007 4:13 PM, Moritz Lennert < >>>>>> [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>>>> <mailto: [EMAIL PROTECTED]>> wrote: >>>>>> >>>>>> On 14/12/07 14:48, Andre Hauptfleisch wrote: >>>>>> > Good day guys, >>>>>> > >>>>>> > I came across a problem in the v.generalize module. I do the >>>>>> >>>>>> following: >>>>>> > v.generalize [EMAIL PROTECTED] output=myvect_smooth type=line >>>>>> > method=hermite threshold=10 >>>>>> > >>>>>> > I then do a v.out.svg and noticed the following line in the >>>>>> > svg >>>> file: >>>>>> > <path gg:cat="31" d="M 111.500000 -80.500000 l 8.734748 >>>>>> > 4.771559 9.907176 6.337565 nan nan nan nan nan nan nan nan nan >>>>>> > nan" /> >>>>>> > >>>>>> > Any idea how I can get rid of those nan's? They cause stuff >>>>>> > such >>>> as >>>> >>>>>> > v.to.rast to hang. >>>>>> >>>>>> I cannot reproduce this with the speafish60 dataset: >>>>>> >>>>>> v.out.svg [EMAIL PROTECTED] output=roads type=line >>>>>> precision=6 layer=1 >>>>>> >>>>>> and >>>>>> >>>>>> v.generalize [EMAIL PROTECTED] output=roads_smooth type=line >>>>>> method=hermite threshold=10 look_ahead=7 reduction=50 slide= 0.5 >>>>>> angle_thresh=3 degree_thresh=0 closeness_thresh=0 >>>> betweeness_thresh=0 >>>> >>>>>> alpha=1.0 beta=1.0 iterations=1 layer=1 >>>>>> >>>>>> v.out.svg [EMAIL PROTECTED] output=roads_smooth type=line >>>>>> precision=6 layer=1 >>>>>> >>>>>> Both give me svg files without nan's. >>>>>> >>>>>> Can you reproduce this with spearfish data ? Can you look at the >>>> line >>>> >>>>>> with cat=31 in your grass vector (maybe in v.digit) and see if >>>>>> there >>>> is >>>> >>>>>> anything abnormal about it ? >>>>>> >>>>>> Moritz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Groete, >>>>>> Andre Hauptfleisch >>>>>> >>>>>> M: 082 5722 469 >>>>>> F: 086 687 1106 >>>>>> E: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>> -- >>>> Groete, >>>> Andre Hauptfleisch >>>> >>>> M: 082 5722 469 >>>> F: 086 687 1106 >>>> E: [EMAIL PROTECTED] >>>> _______________________________________________ >>>> grass-user mailing list >>>> [email protected] >>>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> _______________________________________________ >>> grass-user mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user -- <:3 )---- Wolf Bergenheim ----( 8:> _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
