#1878: Metric distance option for v.distance in latlon regions
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.4.3
Component: Default | Version: unspecified
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
It would be nice if v.distance could calculate distance (e.g. minimum
distance between to and from features) in a metric value like meters even
when it works in a latlon region. Currently, it only calculates distance
in the default units of the region.
#1878: Metric distance option for v.distance in latlon regions
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by hamish):
Replying to [comment:2 cmbarton]:
> You're right about it not being a bug fix. I'll bump it up to
> 6.4.4 (or is 6.5 and above better?) and above.
I guess the normal procedure would be to add it to trunk first, and then
see how invasive the change was before considering backporting it to 6.x.
If destined for 6.4.4 for sure and the 6.4.3 branch is frozen for release
as it is now, I'd backport from trunk to devbranch_6 and then (and I'm not
very good at remembering this part) make sure to add it to the list of
stuff to backport in the trac dev wiki pages so it doesn't get forgotten
once the release branch 64 is reopened post release.
#1878: Metric distance option for v.distance in latlon regions
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by mmetz):
* milestone: 6.5.0 => 7.0.0
Comment:
Replying to [comment:1 hamish]:
> if so it shouldn't be too hard to get, G_geodesic_distance() is always
returning meters, so we already know the number internally.
This does not work for v.distance. You would need to enhance
G_distance_point_to_line_segment() with the options of
Vect_line_distance() or write a new function
Vect_line_geodesic_distance().
#1878: Metric distance option for v.distance in latlon regions
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
So it hasn't yet been done because it is more work than it initially
seemed. Well maybe it can happen for GRASS 7. Not an urgent thing, but it
would be nice...
#1878: Metric distance option for v.distance in latlon regions
----------------------------------+-----------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.distance, geodesic | Platform: All
Cpu: All |
----------------------------------+-----------------------------------------
Changes (by hamish):
* keywords: v.distance => v.distance, geodesic
* platform: Unspecified => All
* cpu: Unspecified => All
Comment:
ah, calculating the great circle distance between every node of a polyline
could be rather computationally expensive, but it is possible if you don't
mind the wait.
to clarify: does the current version report decimal degrees (aka garbage)
for v.distance in a lat/lon location? If so it at least deserves a
warning, and in general a fatal error is better than plausible but
actually meaningless results.