Fwd: Patch to provide GeodesicDistance for geopy

[Brian Beck]

---------- Forwarded message ----------
From: Brian Beck <exo...@gmail.com>
Date: Thu, Jul 21, 2011 at 5:39 PM
Subject: Re: Patch to provide GeodesicDistance for geopy
To: Charles Karney <charles...@sri.com>


Thanks, Charles! I'll forward this to the geopy list, where the more active maintainers will see it. (I don't have much time for geopy anymore and it's now maintained by Mike Tigas and Calvin Spealman.)

My only comment from a glance: I would catch ImportError on GeographicLib, log it (warn or info level), and continue to use VincentyDistance by default if the library isn't installed.

Nice work and keep geohacking,

Brian

On Thu, Jul 21, 2011 at 1:31 PM, Charles Karney <charles...@sri.com> wrote:

geopy contains VincentyDistance which returns the geodesic distance
between two points.  This suffers from two defects:

* it fails to converge from some pairs of points
* where it converges the error is rather large (about 0.5mm)

The attached patch provides GeodesicDistance which cures both these
defects.  It uses the geodesic functionality provided by GeographicLib
and assumes that GeographicLib.py is in your path.  The function is
roughly as fast as VincentyDistance (the "destination" function is
somewhat faster, the "distance" function is somewhat slower).
GeographicLib.py also can compute

* the area of geodesic polygons (accurate to about 0.1 m^2 per vertex
 for the WGS84 ellipsoid)

* the differential properties of a geodesic; this allows various
 geodesic problems (maritime median lines, geodesic intersections,
 etc.) to be solved rapidly using Newton's method.

GeographicLib is available under the MIT/X11 license at

 http://geographiclib.sourceforge.net

--
Charles Karney <charles...@sri.com>
SRI International, Princeton, NJ 08543-5300

Tel: +1 609 734 2312
Fax: +1 609 734 2662

--
Brian Beck / www.brianbeck.com

--
Brian Beck / www.brianbeck.com

[Charles Karney]

On 07/21/11 20:39, Brian Beck wrote:
> My only comment from a glance: I would catch ImportError on
> GeographicLib, log it (warn or info level), and continue to use
> VincentyDistance by default if the library isn't installed.

Checking for GeographicLib is prudent, of course.  A question for the
python experts:  where should GeographicLib.py get installed?  At
present, I put it in

  /usr/local/share/GeographicLib/python/GeographicLib.py

But perhaps

  /usr/lib/python/site-packages/GeographicLib.py

is a more canonical location.

An alternative would be to distribute GeographicLib.py as part of geopy.
This would give you a stable set of software to distribute and to test
against (at the cost of periodically keeping synchronized with the base
distribution of GeographicLib).

A couple of additional points:

(1) Change the test for failure for for antipodal points to a test for
success!  (There *is* a shortest path in this case -- over the pole --
and it is returned.)

(2) This is my first serious foray into python.  I would welcome any
advice for how best to structure a  package like GeographicLib.  I had
wanted to separate the C++ classes into separate files such as

  GeographicLib/Geodesic.py

But that seemed to introduce the need to deal with repeating naming,
e.g.,

  GeographicLib.Geodesic.Geodesic.WGS84

What's the "right" way of handling this?

  --Charles

[Mike Tigas]

On Jul 22, 9:27 am, Charles Karney <charles.kar...@gmail.com> wrote:
>
> Checking for GeographicLib is prudent, of course.  A question for the
> python experts:  where should GeographicLib.py get installed?  At
> present, I put it in
>   /usr/local/share/GeographicLib/python/GeographicLib.py
>
> But perhaps
>   /usr/lib/python/site-packages/GeographicLib.py
>
> is a more canonical location.

Since you’re new to Python, you can leave it in site-packages while
you’re developing it. Python automatically searches many locations
when you attempt to import anything: http://docs.python.org/tutorial/modules.html#the-module-search-path

If you are interested in actually distributing it, you can package it
so that people can install it with easy_install.

Where is the source for the Python version of GeographicLib? Is it
included in the C++ package or is this something that you are working
on?

If GeographicLib.py isn’t mature, I’d go with Brian’s suggestion that
we fall back to the less-accurate-but-simpler Vincenty method if
GeographicLib isn’t installed. (*Recommend* that it is installed, but
do not *require* it to use GeoPy.) i.e.:

try:
import GeographicLib
except ImportError:
GeographicLib = None

[...]

if GeographicLib:
# use GeographicLib tools
else:
# use Vincenty method

[Mike Tigas]

On Jul 22, 9:27 am, Charles Karney <charles.kar...@gmail.com> wrote:

> (2) This is my first serious foray into python.  I would welcome any
> advice for how best to structure a  package like GeographicLib.  I had
> wanted to separate the C++ classes into separate files such as
>
>   GeographicLib/Geodesic.py
>
> But that seemed to introduce the need to deal with repeating naming,
> e.g.,
>
>   GeographicLib.Geodesic.Geodesic.WGS84
>
> What's the "right" way of handling this?

As per http://www.python.org/dev/peps/pep-0008/ (PEP 8, Style Guide
for Python Code), package/module names should be lowercase and class
names should be CamelCase.

geographiclib/
__init__.py
geodesic.py
...

-----

Within "geodesic.py":

class Geodesic(object):
#...

-----

I *think* the generally-accepted style is to provide explicit imports
of the classes and methods you’re using, rather than importing the
full library namespace. (Unless this results in a name conflict.) For
example:

from geographiclib.geodesic import Geodesic

wgs = Geodesic.WGS84
foo = Geodesic(...)
# etc...

[Charles Karney]

Thanks for the advice.  I would prefer to split the
code into several files.

[Charles Karney]

On Thursday, August 11, 2011 3:17:53 PM UTC-4, Mike Tigas wrote:

Where is the source for the Python version of GeographicLib? Is it
included in the C++ package or is this something that you are working
on?

 
Currently the python version is included in the C++ distribution.  (And,
for the record, the python version implements just the geodesic routines
from GeographicLib; these are the routines which are clearly better than
the alternatives.)  The source code repository is

git://geographiclib.git.sourceforge.net/gitroot/geographiclib/geographiclib

I would definitely expect to do some tinkering with the python to
conform to the python guidelines.  I'll plan to get this into the next
release (in a week or so).  I don't expect there to be any significant
changes to the basic algorithms; these have be stable for a year now.

  -Charles

[Charles Karney]

On Friday, August 12, 2011 11:19:20 AM UTC-4, Charles Karney wrote:

Thanks for the advice.  I would prefer to split the
code into several files.

I reread this reply and it sounds ambiguous.  The "would" is
expressing concurrence and not disagreement.

[Charles Karney]

I've reworked the python port of GeographicLib and incorporated this
into version 1.14.  The full version of GeographicLib (documentation,
C++, python, Javascript) is available at

  http://geographiclib.sf.net

A standalone python distribution is available at

  http://pypi.python.org/pypi/geographiclib

Feedback is welcome.