v.distance in Long/Lat Locations on GRASS 7.0

[landam]

Reported by micha on 26 Aug 2014 09:34 UTC In stable version 6.4, when working in a Long-Lat LOCATION, v.distance returns geodesic distance on a sphere in meters (in the cases of point to point, and point to line).

In GRASS 7.0 this feature is lost, and distances are always returned in the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic distance should be the preferred behavior.

Migrated-From: https://trac.osgeo.org/grass/ticket/2402

[landam]

Attachment from mlennert on 4 Sep 2014 11:43 UTC patch for enabling geodesic distances in LL-locations https://trac.osgeo.org/grass/attachment/ticket/2402/vdistance_ll.diff

[landam]

Comment by wenzeslaus on 4 Sep 2014 02:55 UTC This would be a blocker for 7.0 release unless the current (7.0's) behavior will be a default and requested requested behavior optional.

See also https://trac.osgeo.org/grass/ticket/2401 for 6.4.

[landam]

Comment by mlennert on 4 Sep 2014 11:21 UTC Replying to [comment:1 wenzeslaus]:

This would be a blocker for 7.0 release unless the current (7.0's) behavior will be a default and requested requested behavior optional.

I think that geodesic distances in LL-locations should stay the default behaviour, but even if we decide to make it optional, it still needs to be implemented [1].

Markus M: as you implemented the new version of v.distance, can you tell us quickly what needs to be done ?

Moritz

[1] https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.distance/distance.c#L6

[landam]

Comment by mlennert on 4 Sep 2014 11:43 UTC In the attached patch, I had a quick go at it, in line with the patch for grass6.

Needs testing, though.

Moritz

[landam]

Comment by mmetz on 10 Sep 2014 18:56 UTC Replying to [ticket:2402 micha]:

In stable version 6.4, when working in a Long-Lat LOCATION, v.distance returns geodesic distance on a sphere in meters (in the cases of point to point, and point to line).

In GRASS 7.0 this feature is lost, and distances are always returned in the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic distance should be the preferred behavior.

Fixed for trunk in https://trac.osgeo.org/grass/changeset/61850.

[landam]

Comment by mlennert on 11 Sep 2014 09:25 UTC Replying to [comment:4 mmetz]:

Replying to [ticket:2402 micha]:

In stable version 6.4, when working in a Long-Lat LOCATION, v.distance returns geodesic distance on a sphere in meters (in the cases of point to point, and point to line).

In GRASS 7.0 this feature is lost, and distances are always returned in the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic distance should be the preferred behavior.

Fixed for trunk in https://trac.osgeo.org/grass/changeset/61850.

With the NC-data reprojected to EPSG 4326, I get the following now:

v.distance -p from=comm_colleges to=comm_colleges upload=dist col=dist dmin=0.0001

Finding nearest features...
 100%
 100%
from_cat|dist
1|null
2|null
3|null
[...]
55|null
56|null
57|null
58|null
 100%
58 categories - no nearest feature found

Whereas the same command in the NC-location gives me the expected list of distances.

Moritz

[landam]

Comment by mmetz on 11 Sep 2014 09:56 UTC Replying to [comment:5 mlennert]:

Replying to [comment:4 mmetz]:

Replying to [ticket:2402 micha]:

In stable version 6.4, when working in a Long-Lat LOCATION, v.distance returns geodesic distance on a sphere in meters (in the cases of point to point, and point to line).

In GRASS 7.0 this feature is lost, and distances are always returned in the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic distance should be the preferred behavior.

Fixed for trunk in https://trac.osgeo.org/grass/changeset/61850.

With the NC-data reprojected to EPSG 4326, I get the following now:

v.distance -p from=comm_colleges to=comm_colleges upload=dist col=dist dmin=0.0001

Finding nearest features... 100% 100% from_cat|dist 1|null 2|null 3|null [...] 55|null 56|null 57|null 58|null 100% 58 categories - no nearest feature found

> 

Oops. Fixed in https://trac.osgeo.org/grass/changeset/61861.

[landam]

Comment by mlennert on 14 Sep 2014 11:15 UTC Replying to [comment:6 mmetz]:

Replying to [comment:5 mlennert]:

Replying to [comment:4 mmetz]:

Replying to [ticket:2402 micha]:

In stable version 6.4, when working in a Long-Lat LOCATION, v.distance returns geodesic distance on a sphere in meters (in the cases of point to point, and point to line).

In GRASS 7.0 this feature is lost, and distances are always returned in the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic distance should be the preferred behavior.

Fixed for trunk in https://trac.osgeo.org/grass/changeset/61850.

With the NC-data reprojected to EPSG 4326, I get the following now:

v.distance -p from=comm_colleges to=comm_colleges upload=dist col=dist dmin=0.0001

Finding nearest features... 100% 100% from_cat|dist 1|null 2|null 3|null [...] 55|null 56|null 57|null 58|null 100% 58 categories - no nearest feature found

> 

Oops. Fixed in https://trac.osgeo.org/grass/changeset/61861.

I just found a difference in distances calculated with grass6 and grass7 for points to areas (see explanation in https://trac.osgeo.org/grass/ticket/2401). Needs checking.

[landam]

Comment by mmetz on 15 Sep 2014 18:41 UTC Replying to [comment:7 mlennert]:

I just found a difference in distances calculated with grass6 and grass7 for points to areas (see explanation in https://trac.osgeo.org/grass/ticket/2401). Needs checking.

G6 and G7 produced nearly identical results after the last change to v.distance in trunk, but now (https://trac.osgeo.org/grass/changeset/61978) there is Vect_line_geodesic_distance() available in trunk and v.distance makes use of it (https://trac.osgeo.org/grass/changeset/61979). The results in latlong are now more similar to the results in the original NC projection. In particular, the larger deviations present in G6 have now disappeared in trunk.

[landam]

Modified by @landam on 12 May 2016 06:44 UTC

[landam]

Modified by @landam on 25 Aug 2016 15:51 UTC

[landam]

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

[landam]

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

[landam]

Comment by @landam on 28 Jan 2018 10:51 UTC What is status of this issue?

[landam]

Modified by neteler on 12 Jun 2018 20:48 UTC

[landam]

Comment by @landam on 25 Sep 2018 16:51 UTC All enhancement tickets should be assigned to 7.6 milestone.

[landam]

Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed