[GRASS-user] nan values by v.generalize

GRASS GRASS user
1

Good day guys,

I came across a problem in the v.generalize module. I do the following:
v.generalize input=myvect@test 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:

Any idea how I can get rid of those nan’s? They cause stuff such as v.to.rast to hang.

Regards,
Andre

2

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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line precision=6 layer=1

and

v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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

3

I’ll try to upload the vector layer I used to an ftp site. What would the best output format be? DXF?

On Dec 14, 2007 4:13 PM, Moritz Lennert < mlennert@club.worldonline.be> 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 input=myvect@test 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:

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 input=roads@PERMANENT output=roads type=line precision=6 layer=1

and

v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com

4

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 < mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line precision=6
    layer=1

    and

    v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>

5

I’ve attached the myvect and myvect_smooth files.

Thanks for the help!!

On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be > 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 < mlennert@club.worldonline.be

<mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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:

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 input=roads@PERMANENT output=roads type=line precision=6
layer=1

and

v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com mailto:[ahaupt@gmail.com](mailto:ahaupt@gmail.com)

–
Groete,
Andre Hauptfleisch

M: 082 5722 469
F: 086 687 1106
E: ahaupt@gmail.com

(attachments)

myvect.txt (2.44 KB)
myvect_smooth.txt (3.42 KB)

6

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

On Dec 14, 2007 4:41 PM, Andre Hauptfleisch <ahaupt@gmail.com> wrote:

I've attached the myvect and myvect_smooth files.

Thanks for the help!!

On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be >
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 < mlennert@club.worldonline.be
>
>
>
> > <mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line precision=6
> > layer=1
> >
> > and
> >
> > v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>
>
>

--
Groete,
Andre Hauptfleisch

M: 082 5722 469
F: 086 687 1106
E: ahaupt@gmail.com
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

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 <ahaupt@gmail.com> wrote:
> I've attached the myvect and myvect_smooth files.
>
> Thanks for the help!!
>
>
>
>
> On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be >
>
> 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 <
> > > mlennert@club.worldonline.be
> > >
> > >
> > >
> > > <mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line
> > > precision=6 layer=1
> > >
> > > and
> > >
> > > v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>
>
> --
> Groete,
> Andre Hauptfleisch
>
> M: 082 5722 469
> F: 086 687 1106
> E: ahaupt@gmail.com
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

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 <dylan.beaudette@gmail.com> 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 <ahaupt@gmail.com> wrote:
> > I've attached the myvect and myvect_smooth files.
> >
> > Thanks for the help!!
> >
> >
> >
> >
> > On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be >
> >
> > 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 <
> > > > mlennert@club.worldonline.be
> > > >
> > > >
> > > >
> > > > <mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line
> > > > precision=6 layer=1
> > > >
> > > > and
> > > >
> > > > v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>
> >
> > --
> > Groete,
> > Andre Hauptfleisch
> >
> > M: 082 5722 469
> > F: 086 687 1106
> > E: ahaupt@gmail.com
> > _______________________________________________
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
>
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

9

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 <dylan.beaudette@gmail.com> 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 <ahaupt@gmail.com> wrote:

I've attached the myvect and myvect_smooth files.

Thanks for the help!!

On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be >

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 <
mlennert@club.worldonline.be

<mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line
precision=6 layer=1

    and

    v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>

--
Groete,
Andre Hauptfleisch

M: 082 5722 469
F: 086 687 1106
E: ahaupt@gmail.com
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--

<:3 )---- Wolf Bergenheim ----( 8:>

10

On Sunday 16 December 2007 03:16:52 am 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

That sounds reasonable to me. Once it is posted, I will try and construct a
couple pathological cases to test it against.

cheers,

Dylan

On Dec 15, 2007 8:36 PM, Dylan Beaudette <dylan.beaudette@gmail.com> 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 <ahaupt@gmail.com> wrote:
> > > I've attached the myvect and myvect_smooth files.
> > >
> > > Thanks for the help!!
> > >
> > >
> > >
> > >
> > > On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be
> > > >
> > >
> > > 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 <
> > > > > mlennert@club.worldonline.be
> > > > >
> > > > >
> > > > >
> > > > > <mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line
> > > > > precision=6 layer=1
> > > > >
> > > > > and
> > > > >
> > > > > v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>
> > >
> > > --
> > > Groete,
> > > Andre Hauptfleisch
> > >
> > > M: 082 5722 469
> > > F: 086 687 1106
> > > E: ahaupt@gmail.com
> > > _______________________________________________
> > > grass-user mailing list
> > > grass-user@lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
> > _______________________________________________
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user

11

Daniel Bundala wrote:

As I mentioned in my previous post, a solution is to translate the
corresponding points little bit.

be careful that moving a vertex a little bit in a location where the
units is meters might seem harmless but the same change in a lat/lon
location could be damaging. the location's projection units could just
as well be km, lightyears, ... too.

I would think it better to do the operation in 2 passes if some
cleaning is needed, and only fudge the data as a last resort.

maybe the v.clean remove small angles tool helps here.

2c,
Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

12

The patch is attached. Hope it works.

Daniel

On Dec 16, 2007 7:03 PM, Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:

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 <dylan.beaudette@gmail.com> 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 <ahaupt@gmail.com> wrote:
>>>> I've attached the myvect and myvect_smooth files.
>>>>
>>>> Thanks for the help!!
>>>>
>>>>
>>>>
>>>>
>>>> On Dec 14, 2007 4:53 PM, Moritz Lennert <mlennert@club.worldonline.be >
>>>>
>>>> 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 <
>>>>>> mlennert@club.worldonline.be
>>>>>>
>>>>>>
>>>>>>
>>>>>> <mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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 input=roads@PERMANENT output=roads type=line
>>>>>> precision=6 layer=1
>>>>>>
>>>>>> and
>>>>>>
>>>>>> v.generalize input=roads@PERMANENT 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 input=roads_smooth@user1 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: ahaupt@gmail.com <mailto:ahaupt@gmail.com>
>>>> --
>>>> Groete,
>>>> Andre Hauptfleisch
>>>>
>>>> M: 082 5722 469
>>>> F: 086 687 1106
>>>> E: ahaupt@gmail.com
>>>> _______________________________________________
>>>> grass-user mailing list
>>>> grass-user@lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

--

<:3 )---- Wolf Bergenheim ----( 8:>

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

(attachments)

smoothing.diff (746 Bytes)

13

Daniel Bundala wrote:

> > As I mentioned in my previous post, a solution is to translate
> > the corresponding points little bit.

....

The patch is attached. Hope it works.

May I suggest replacing 1e-12 with GRASS_EPSILON? (defined in gis.h)

=== message truncated ===>

everyone, please do.

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

14

Hi Daniel,

Guess I should’ve investigated the data a bit closer, but I found a quick workaround so I didn’t really bother too much.

I generate these vectors with a little app. It should be easy enough to detect these dodgy points before sending them to grass.

Thanks!

Andre

On Dec 15, 2007 3:38 PM, Daniel Bundala <bundala@gmail.com> 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

On Dec 14, 2007 4:41 PM, Andre Hauptfleisch <ahaupt@gmail.com > wrote:

I’ve attached the myvect and myvect_smooth files.

Thanks for the help!!

On Dec 14, 2007 4:53 PM, Moritz Lennert < mlennert@club.worldonline.be >
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 < mlennert@club.worldonline.be

<mailto: mlennert@club.worldonline.be>> 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 input=myvect@test 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:

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 input=roads@PERMANENT output=roads type=line precision=6
layer=1

and

v.generalize input=roads@PERMANENT 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 input= roads_smooth@user1 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: ahaupt@gmail.com mailto:[ahaupt@gmail.com](mailto:ahaupt@gmail.com)

–
Groete,
Andre Hauptfleisch

M: 082 5722 469
F: 086 687 1106
E: ahaupt@gmail.com

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user