v.select: doubtful result with the default overlap operator selecting areas with lines

[mlennert]

Trying to select areas with lines, I get a result using the overlap operator that I don't really understand, and which I suspect being a bug.

Using the following command in the attached location, test_vselect mapset:

v.select ain=test_polys bin=test_line atype=area btype=line out=result_overlap op=overlap

I get a result of only three areas selected (see attached map) where, IMHO, all 41 should be.

I'll try to diagnose this further when I have the time...

The attached location includes the results of runs with op=intersects, op=crosses and op=overlaps which provide the results I expect.

[mlennert]

location with test data in mapset test_vselect

[mlennert]

image of overlap results

[mmetz]

In 72746:

Vlib: fix with_z = 0 for Vect_line_check_intersection2() and Vect_line_intersection2(), fixes #3567

[mmetz]

In 72747:

Vlib: fix with_z = 0 for Vect_line_check_intersection2() and Vect_line_intersection2(), fixes #3567 (backport trunk r72746)

[mmetz]

Replying to mlennert:

Trying to select areas with lines, I get a result using the overlap operator that I don't really understand, and which I suspect being a bug.

Using the following command in the attached location, test_vselect mapset:

v.select ain=test_polys bin=test_line atype=area btype=line out=result_overlap op=overlap

I get a result of only three areas selected (see attached map) where, IMHO, all 41 should be.

The problem was not the overlap operator of v.select, but instead that the vector test_line is 3D, and one of the underlying library functions did not ignore z as it should have done. This bug has been fixed in trunk and relbr74 with r72746,7.

[mlennert]

Replying to mmetz:

Replying to mlennert:

Trying to select areas with lines, I get a result using the overlap operator that I don't really understand, and which I suspect being a bug.

Using the following command in the attached location, test_vselect mapset:

v.select ain=test_polys bin=test_line atype=area btype=line out=result_overlap op=overlap

I get a result of only three areas selected (see attached map) where, IMHO, all 41 should be.

The problem was not the overlap operator of v.select, but instead that the vector test_line is 3D, and one of the underlying library functions did not ignore z as it should have done. This bug has been fixed in trunk and relbr74 with r72746,7.

Thanks a lot ! Sorry, should have noticed the 3D nature of the vector myself. I guess there must have been a message at import which I didn't see.

This obviously raises the question of whether v.select should always ignore 3D or whether a flag (-3) should allow enabling it so that if one wants to check spatial relation in 3D this is possible.

[mmetz]

Replying to mlennert:

Replying to mmetz:

Replying to mlennert:

Trying to select areas with lines, I get a result using the overlap operator that I don't really understand, and which I suspect being a bug.

Using the following command in the attached location, test_vselect mapset:

v.select ain=test_polys bin=test_line atype=area btype=line out=result_overlap op=overlap

I get a result of only three areas selected (see attached map) where, IMHO, all 41 should be.

The problem was not the overlap operator of v.select, but instead that the vector test_line is 3D, and one of the underlying library functions did not ignore z as it should have done. This bug has been fixed in trunk and relbr74 with r72746,7.

Thanks a lot ! Sorry, should have noticed the 3D nature of the vector myself. I guess there must have been a message at import which I didn't see.

This obviously raises the question of whether v.select should always ignore 3D or whether a flag (-3) should allow enabling it so that if one wants to check spatial relation in 3D this is possible.

This is not possible because Vect_segment_intersection() does not support 3D coordinates.

Also note that 3D topology does not exist yet in GRASS, e.g. a purely vertical line can cause problems, because it is marked as degenerate at the corresponding nodes.