In GRASS7, v.distance can now calculate distances from
point,line,boundary,centroid,area to
point,line,boundary,centroid,area.
In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.
Markus M
- Great improvement
On Sat, Oct 13, 2012 at 3:51 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:
In GRASS7, v.distance can now calculate distances from
point,line,boundary,centroid,area to
point,line,boundary,centroid,area.In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.Markus M
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Yip, great stuff.
On 14 October 2012 04:06, Paulo van Breugel <p.vanbreugel@gmail.com> wrote:
- Great improvement
On Sat, Oct 13, 2012 at 3:51 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:
In GRASS7, v.distance can now calculate distances from
point,line,boundary,centroid,area to
point,line,boundary,centroid,area.In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.Markus M
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
On 13/10/12 15:51, Markus Metz wrote:
In GRASS7, v.distance can now calculate distances from
point,line,boundary,centroid,area to
point,line,boundary,centroid,area.
So how does it calculate the distance between two lines (lines or boundaries) ? Between closest vertices ? What about lines that cross several other lines, or lines that cross each other at several points ?
In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.
AFAIK, this was due to the conceptual issue mentioned above. I think that the answer has to be clearly explained in the manual because they are not as straightforward. And a first rapid test shows that these issues seem to be problematic in your implementation:
http://164.15.12.207/grass/v_distance_lines.png
http://164.15.12.207/grass/v_distance_areas.png
red: from features (quickly digitized test data available here: http://164.15.12.207/grass/v_distance_testdata.tgz)
black: to features (roadsmajor and urbanarea from nc_spm_08)
green: connecting lines between from and to feature
Moritz
On Mon, Oct 15, 2012 at 3:09 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 13/10/12 15:51, Markus Metz wrote:
In GRASS7, v.distance can now calculate distances from
point,line,boundary,centroid,area to
point,line,boundary,centroid,area.So how does it calculate the distance between two lines (lines or
boundaries) ? Between closest vertices ? What about lines that cross several
other lines, or lines that cross each other at several points ?
For lines to lines, say line A to line B, it calculates shortest
distance of each vertex in A with each segment (not vertex) in B. So
far, this is the same like in the original version, results are
identical. Now if line A is a line or boundary, it calculates the
shortest distance of each vertex in B to each segment in A.
Additionally, it checks for intersections. In case of intersections,
the first intersection found is used and the distance set to zero.
For lines to areas, it behaves similar to the original version. If a
line is inside an area, the distance is set to zero. The first point
of the line inside the area is used as common point. The distance is
also set to zero if the line intersects with the outer ring or any of
the inner rings (isles), in which case the fist intersection is used
as common point.
For areas to areas, the module checks first for overlap or if one area
is (partially) inside the other area. This is computationally quite
intensive. If the outer rings of the two areas do not overlap, the
distance is calculated as above for lines to lines, treating the outer
rings as two lines. Again, the first point encountered falling into an
area is used as common point, or the first intersection point.
For anything else than points to lines, there can be several common
points with distance = zero, and the closest location could then be
several points or several lines or several areas (result of overlay).
For v.distance, I choose to select a single point, and not create an
overlay like v.overlay.
In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.AFAIK, this was due to the conceptual issue mentioned above. I think that
the answer has to be clearly explained in the manual because they are not as
straightforward. And a first rapid test shows that these issues seem to be
problematic in your implementation:http://164.15.12.207/grass/v_distance_lines.png
http://164.15.12.207/grass/v_distance_areas.pngred: from features (quickly digitized test data available here:
http://164.15.12.207/grass/v_distance_testdata.tgz)
black: to features (roadsmajor and urbanarea from nc_spm_08)
green: connecting lines between from and to feature
Thanks for testing! These issues should be fixed, at least conforming
to my explanation above, in r53401.
Markus M
On 15/10/12 16:30, Markus Metz wrote:
So how does it calculate the distance between two lines (lines or
boundaries) ? Between closest vertices ? What about lines that cross several
other lines, or lines that cross each other at several points ?For lines to lines, say line A to line B, it calculates shortest
distance of each vertex in A with each segment (not vertex) in B. So
far, this is the same like in the original version, results are
identical.
The original version did not have line to line...
Now if line A is a line or boundary, it calculates the
shortest distance of each vertex in B to each segment in A.
Additionally, it checks for intersections. In case of intersections,
the first intersection found is used and the distance set to zero.For lines to areas, it behaves similar to the original version. If a
line is inside an area, the distance is set to zero. The first point
of the line inside the area is used as common point. The distance is
also set to zero if the line intersects with the outer ring or any of
the inner rings (isles), in which case the fist intersection is used
as common point.For areas to areas, the module checks first for overlap or if one area
is (partially) inside the other area. This is computationally quite
intensive. If the outer rings of the two areas do not overlap, the
distance is calculated as above for lines to lines, treating the outer
rings as two lines. Again, the first point encountered falling into an
area is used as common point, or the first intersection point.For anything else than points to lines, there can be several common
points with distance = zero, and the closest location could then be
several points or several lines or several areas (result of overlay).
For v.distance, I choose to select a single point, and not create an
overlay like v.overlay.
Thanks. I think this should go into the man page.
In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.AFAIK, this was due to the conceptual issue mentioned above. I think that
the answer has to be clearly explained in the manual because they are not as
straightforward. And a first rapid test shows that these issues seem to be
problematic in your implementation:http://164.15.12.207/grass/v_distance_lines.png
http://164.15.12.207/grass/v_distance_areas.pngred: from features (quickly digitized test data available here:
http://164.15.12.207/grass/v_distance_testdata.tgz)
black: to features (roadsmajor and urbanarea from nc_spm_08)
green: connecting lines between from and to featureThanks for testing! These issues should be fixed, at least conforming
to my explanation above, in r53401.
Much better, thanks ! Just one issue still with the area2area case for the test polygon with cat=2:
http://164.15.12.207/grass/v_distance_areas2.png
The connection line/point doesn't touch the the polygon in the from map.
Moritz
On Tue, Oct 16, 2012 at 12:52 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 15/10/12 16:30, Markus Metz wrote:
So how does it calculate the distance between two lines (lines or
boundaries) ? Between closest vertices ? What about lines that cross
several
other lines, or lines that cross each other at several points ?For lines to lines, say line A to line B, it calculates shortest
distance of each vertex in A with each segment (not vertex) in B. So
far, this is the same like in the original version, results are
identical.The original version did not have line to line...
What I meant was that this is equivalent to the shortest distance of
several points to a line, regarding points as line vertices.
In GRASS 6, v.distance can calculate distances only from
point,centroid to point,line,boundary,centroid,area.AFAIK, this was due to the conceptual issue mentioned above. I think that
the answer has to be clearly explained in the manual because they are not
as
straightforward. And a first rapid test shows that these issues seem to
be
problematic in your implementation:http://164.15.12.207/grass/v_distance_lines.png
http://164.15.12.207/grass/v_distance_areas.pngred: from features (quickly digitized test data available here:
http://164.15.12.207/grass/v_distance_testdata.tgz)
black: to features (roadsmajor and urbanarea from nc_spm_08)
green: connecting lines between from and to featureThanks for testing! These issues should be fixed, at least conforming
to my explanation above, in r53401.Much better, thanks ! Just one issue still with the area2area case for the
test polygon with cat=2:http://164.15.12.207/grass/v_distance_areas2.png
The connection line/point doesn't touch the the polygon in the from map.
But it is inside the polygon of the 'from' map. In this
implementation, any shared location is as good as any other.
Calculating an intersection is costlier than to check if a vertex is
inside a polygon. The vertex of the boundary of the 'to' area is
inside the 'from' area, thus a common location. For speed reasons, the
distance is set to zero and no further tests are done.
The results can be unexpected for 'to' areas with isles, because
v.distance (in all versions) does not require a 'to' feature to have a
category, which also means that isles inside areas which themselves
can be areas without centroids are regarded as valid 'to' features,
just without category. But even though the results can be unexpected,
I would leave them as such, otherwise 'to' feature would need to have
a category, potentially leading to also different results for points
to lines which has always been supported.
Markus M
On 16/10/12 10:02, Markus Metz wrote:
On Tue, Oct 16, 2012 at 12:52 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 15/10/12 16:30, Markus Metz wrote:
So how does it calculate the distance between two lines (lines or
boundaries) ? Between closest vertices ? What about lines that cross
several
other lines, or lines that cross each other at several points ?For lines to lines, say line A to line B, it calculates shortest
distance of each vertex in A with each segment (not vertex) in B. So
far, this is the same like in the original version, results are
identical.The original version did not have line to line...
What I meant was that this is equivalent to the shortest distance of
several points to a line, regarding points as line vertices.
Ok.
Much better, thanks ! Just one issue still with the area2area case for the
test polygon with cat=2:http://164.15.12.207/grass/v_distance_areas2.png
The connection line/point doesn't touch the the polygon in the from map.
But it is inside the polygon of the 'from' map. In this
implementation, any shared location is as good as any other.
Calculating an intersection is costlier than to check if a vertex is
inside a polygon. The vertex of the boundary of the 'to' area is
inside the 'from' area, thus a common location. For speed reasons, the
distance is set to zero and no further tests are done.
Ok, this makes it clear. Thanks !
The results can be unexpected for 'to' areas with isles, because
v.distance (in all versions) does not require a 'to' feature to have a
category, which also means that isles inside areas which themselves
can be areas without centroids are regarded as valid 'to' features,
just without category. But even though the results can be unexpected,
I would leave them as such, otherwise 'to' feature would need to have
a category, potentially leading to also different results for points
to lines which has always been supported.
Yes, that's why documentation is so important on all this.
Moritz