bluefeet / geo-distance Goto Github PK

View Code? Open in Web Editor NEW

6.0 3.0 5.0 99 KB

Calculate distances and closest locations. (DEPRECATED)

Home Page: https://metacpan.org/pod/Geo::Distance

License: Other

Perl 100.00%

perl5 cpan deprecated

geo-distance's People

Contributors

Stargazers

Watchers

Forkers

gray anirvan sebastic timretout avar

geo-distance's Issues

Geo::Distance 0.21+0.22 breaks Geo::Distance::XS

New Geo::Distance versions break the Geo::Distance::XS test suite (@gray: FYI):

#   Failed test 'PP version loads XS'
#   at t/02_new_pp.t line 11.
#          got: ''
#     expected: '1'
# Looks like you failed 1 test of 1.
t/02_new_pp.t ...... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Statistical analysis (means: mostly fails with Geo::Distance 0.22):

****************************************************************
Regression 'mod:Geo::Distance'
****************************************************************
Name           	       Theta	      StdErr	 T-stat
[0='const']    	      0.9960	      0.0028	 353.55
[1='eq_0.22']  	     -0.9960	      0.0316	 -31.50

R^2= 0.664, N= 504, K= 2
****************************************************************

Probably it fails also with Geo::Distance 0.21, but I did not verify this.

Dead link in documentation

This link:

http://www.census.gov/cgi-bin/geo/gisfaq?Q5.1

is now dead.

Geo::Distance 0.22 breaks DERF/Travel-Status-DE-IRIS-1.24.tar.gz

Another victim of Geo::Distance 0.22 (and possibly 0.21) (@derf: FYI):

#   Failed test 'get_station_by_location: 10 matches for Foobar'
#   at t/21-iris-stations.t line 86.
#     Structures begin differing at:
#          $got->[1][0] = 'EESA'
#     $expected->[1][0] = 'EE'

#   Failed test 'get_station_by_location(Foobar): correct distance'
#   at t/21-iris-stations.t line 111.
# 0.1808642 and 0.1272343 are not equal to within 0.000001
# Looks like you failed 2 tests of 17.
t/21-iris-stations.t .... 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/17 subtests

Statistical analysis so far:

****************************************************************
Regression 'mod:Geo::Distance'
****************************************************************
Name           	       Theta	      StdErr	 T-stat
[0='const']    	      1.0000	      0.0000	326841869299229888.00
[1='eq_0.22']  	     -1.0000	      0.0000	-85538426647660416.00

R^2= 1.000, N= 73, K= 2
****************************************************************

Geo::Distance was still faster than GIS::Distance::Fast

I think gutting Geo::Distance was premature. Until you can get GIS::Distance to achieve similar performance, you're forcing users to accept a massive performance hit.

See my benchmarking script here:
https://metacpan.org/source/GRAY/Geo-Distance-XS-0.13/ex/benchmark.pl

The numbers published here: https://metacpan.org/pod/Geo::Distance::XS
were for Perl 5.14.2, but running against Perl 5.28.1 the numbers are slightly better, but still are at least an order of magnitude better for Geo::Distance::XS.
And note, that your pure-perl Geo::Distance is faster than your GIS::Distance::Fast in all but one case.

Activate some tests even if DBI is not installed

https://rt.cpan.org/Ticket/Display.html?id=58161

Sat Jun 05 08:58:44 2010

It would be nice to move the "use DBI" check in t/00.t into the SKIP block where the existence of DBD::SQLite is checked. So at least the three tests outside the SKIP block would be executed if DBI is not available.

Regards,
Slaven

Bugs: Typos in the documentation of Geo::Distance

https://rt.cpan.org/Ticket/Display.html?id=58292

Wed Jun 09 22:38:04 2010

Distribution name:
Geo-Distance-0.16<http://search.cpan.org/%7Eblue feet/Geo-Distance-0.16/>

Typos in the documentation:
Section: STABILITY
0.09 - Changed the behavior of the reg_unit funtcion (This should be "function")

Section: PROPERTIES
Old: "When a function needs a lon and lat they must always be in decimal degree format."
New: "When a function needs a longitude and latitude, they must always be in decimal degree format."

Section: Formula
Old: "The availabel formulas are hsin, polar, cos, and mt. hsin is the default and mt/cos are depreciated in favor of hsin. polar should be used when calculating coordinates near the poles."
New: "The available formulas are hsin, polar, cos and mt. hsin is the default and mt/cos are deprecated in favor of hsin. Polar should be used when calculating coordinates near the poles."

Cheers,
Mayukh

Give a man a program and you'll frustrate him for a day.
Teach a man to program and you'll frustrate him for life.

Test fails but looks like it should pass

Test is failing, despite the fact that the values look the same, and an alternate test think it should pass.
Please see below:

$ perl -d -Iblib/lib -Iblib/arch t/issue-github-2.t

Loading DB routines from perl5db.pl version 1.33
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

ok 1 - use Geo::Distance;
[ snip ] 
main::(t/issue-github-2.t:22):  cmp_ok( $new_value, '==', $control_value, 'gcd now produces same result as hsin' );
  DB<1> 
not ok 2 - gcd now produces same result as hsin
#   Failed test 'gcd now produces same result as hsin'
#   at t/issue-github-2.t line 22.
#          got: 12.7265258269778
#     expected: 12.7265258269778
main::(t/issue-github-2.t:23):  cmp_ok( $old_value, '!=', $control_value, 'old gcd did not produce same result as hsin' );
  DB<1> p $new_value
12.7265258269778
  DB<2> p $control_value
12.7265258269778
  DB<3> is($control_value, $new_value, 'new = control')
ok 3 - new = control

Geo-Distance-0.24 test failures

I see the following problem when running the self tests for Geo-Distance-0.24 from CPAN:

# ./Build test 
t/basic.t ........... Cannot find a GIS::Distance::Formula class for Haversine at /usr/pkg/lib/perl5/vendor_perl/5.32.0/GIS/Distance.pm line 24.
t/basic.t ........... Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
t/closest.t ......... skipped: Module 'DBD::SQLite' is not installed
t/issue-github-2.t .. Cannot find a GIS::Distance::Formula class for GreatCircle at /usr/pkg/lib/perl5/vendor_perl/5.32.0/GIS/Distance.pm line 24.
t/issue-github-2.t .. Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
t/issue-github-3.t .. 1/? 
# Failed test 'did not die'
# at t/issue-github-3.t line 14.
# +---------------------------------------------------------+----+---------+
# | GOT                                                     | OP | CHECK   |
# +---------------------------------------------------------+----+---------+
# | Cannot find a GIS::Distance::Formula class for Haversin | IS | <UNDEF> |
# | e at /usr/pkg/lib/perl5/vendor_perl/5.32.0/GIS/Distance |    |         |
# | .pm line 24.\n                                          |    |         |
# +---------------------------------------------------------+----+---------+
# Seeded srand with seed '20200907' from local date.
t/issue-github-3.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

"^" used instead of "**"

Bitwise XOR (^)? Surely that should be exponentiation (**)!

    elsif($self->{formula} eq 'gcd'){
        $c = 2*asin( sqrt(
            ( sin(($lat1-$lat2)/2) )^2 + 
            cos($lat1) * cos($lat2) * 
            ( sin(($lon1-$lon2)/2) )^2
        ) );

New distance formula

This paper describes a new formula that purportedly resolves issues with the Vincenty formula, as well as being faster:
http://arxiv.org/abs/1102.1215

The paper only contains the math, but the accompanying software [1] has C++, Python and JavaScript implementations, so shouldn't be hard to port.

I'd like to eventually implement this in Geo::Distance::XS, but as it's not standalone and is dependent on Geo::Distance for the interface, the latter would have to also support it, or at least not reject unknown formulae.

[1] http://geographiclib.sourceforge.net/

Wrong distances since 0.21

With 0.21 and 0.22 distances calculcated by Geo::Distance seem to be wrong. A test script, which uses Geo::Distance and Math::Trig for caculating a distance:

#!/usr/bin/env perl

use strict;
use warnings;
use Geo::Distance;
use Math::Trig;

my $lon0 = 13.385900;
my $lat0 = 52.484977;
my $lon1 = 13.370897;
my $lat1 = 52.485033;

my $geo = Geo::Distance->new;
print "Geo::Distance $Geo::Distance::VERSION: ", $geo->distance('meter', $lon0,$lat0,$lon1,$lat1), "\n";

{
    my $lon0 = Math::Trig::deg2rad($lon0);
    my $lat0 = Math::Trig::deg2rad(90 - $lat0);
    my $lon1 = Math::Trig::deg2rad($lon1);
    my $lat1 = Math::Trig::deg2rad(90 - $lat1);
    print "Math::Trig: ", Math::Trig::great_circle_distance($lon0, $lat0,
							    $lon1, $lat1, 6372795), "\n";

}

__END__

With Geo::Distance 0.20 the output looks fine:

Geo::Distance 0.20: 1016.03829356047
Math::Trig: 1016.22247060106

Since 0.21 the distance is quite off:

Geo::Distance 0.21: 1668.43606971801
Math::Trig: 1016.22247060106

Square root of negative value

https://rt.cpan.org/Ticket/Display.html?id=49059

Thu Aug 27 02:35:20 2009

Hello, Thanks for a very useful module. I have noticed that certain values of the latitude and longitude cause Geo::Distance to attempt a negative square root when using the Haversine formula. For example, the following:

my $geo = Geo::Distance->new; $geo->distance("mile", 175, 12, -5, -12);

Produces this:

Can't take sqrt of -2.22045e-16 at Geo/Distance.pm line 259.

I suspect this is some floating-point error happening but I don't know of a good way to fix it - maybe adding some small epsilon to each coordinate if they sum to 180? I am using perl 5.10 on Linux 2.6.28.

Best, Mike Lieberman

bluefeet / geo-distance Goto Github PK

geo-distance's People

Contributors

Stargazers

Watchers

Forkers

geo-distance's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs