Re: [Omaha.pm] Geo::Distance (Was: DBH statement isn't closing)

["Sean Baker" <pbaker@omnihotels.com>]

Very cool stuff!  I used the gcd algorithm quite a while ago to do zone
billing for a telecom company.  It worked well if the city long/lats
didn't cross the equator. It didn't account for the bulge in the Earth.

  c = 2 * asin( sqrt(
    ( sin(( lat1 - lat2 )/2) )^2 + 
    cos( lat1 ) * cos( lat2 ) * 
    ( sin(( lon1 - lon2 )/2) )^2
  ) )

Too bad I didn't know Perl then, it would have been much easier.

Sean Baker

-----Original Message-----
From: omaha-pm-bounces+pbaker=omnihotels.com@pm.org
[mailto:omaha-pm-bounces+pbaker=omnihotels.com@pm.org] On Behalf Of Mike
Hostetler
Sent: Thursday, September 21, 2006 8:53 AM
To: Perl Mongers of Omaha, Nebraska USA
Subject: Re: [Omaha.pm] Geo::Distance (Was: DBH statement isn't closing)

> No sweat. What are you using SQLite for? Just curious.

Something you may be interested in. :)

The Geo::Distance module has a method called "closest" in which you
can give it a DBI handle, a latitude, longtude, and a distance and
return the points in the database that are within that distance.  This
is very cool stuff -- I was doing it with shell scripts, gpsbabel, and
a huge XML file.  Doing it with Perl not only makes it easier, it
makes it faster, too.  Check out the details:

http://search.cpan.org/~bluefeet/Geo-Distance-0.11/Distance.pm#closest

The error I was getting wasn't from the Geo::Distance call, but from a
script I wrote that looks up a waypoint name in my SQLite database,
gets it's lat and lon, and then runs Distance->closest.

Why SQLite?  It's portable, fast, and easy to setup.

-- 

Mike Hostetler
http://mike.hostetlerhome.com/
_______________________________________________
Omaha-pm mailing list
Omaha-pm@pm.org
http://mail.pm.org/mailman/listinfo/omaha-pm