geo_coord 0.0.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 7e6b043870b18d1cb3c9ccbf3b7b6270a63e19fc
+  data.tar.gz: c9938260cf2f45f3c255e099891ddcf2ac1747d4
+SHA512:
+  metadata.gz: 482499de585615150a74734bf23c72936bc7bd10c7b14447f7c251f7d7c79c4fa573b232d25e5d7de6468b2da0e2a11890ff36f7466ef8edb4385cffe44b6ebc
+  data.tar.gz: 6d7f5c2a3c52ed6315922edfe8ca7cd2b682e8c51b4a6c9dde7d46b7ec0af77168f3d95f9abc2623aac8a20d16759b128f9065b5506c0402501ddb4b7681efd0

data/.yardopts

@@ -0,0 +1 @@
+--no-private

data/LICENSE.txt

@@ -0,0 +1,22 @@
+The MIT License (MIT)
+
+Copyright (c) 2016 Victor 'Zverok' Shepelev
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,199 @@
+# Geo::Coord—simple geo coordinates class for Ruby
+
+[![Gem Version](https://badge.fury.io/rb/geo_coord.svg)](http://badge.fury.io/rb/geo_coord)
+[![Dependency Status](https://gemnasium.com/zverok/geo_coord.svg)](https://gemnasium.com/zverok/geo_coord)
+[![Build Status](https://travis-ci.org/zverok/geo_coord.svg?branch=master)](https://travis-ci.org/zverok/geo_coord)
+[![Coverage Status](https://coveralls.io/repos/zverok/geo_coord/badge.svg?branch=master)](https://coveralls.io/r/zverok/geo_coord?branch=master)
+
+`Geo::Coord` is a basic class representing `[latitude, longitude]` pair
+and incapsulating related concepts and calculations.
+
+## Features
+
+* Simple storage for geographical latitude & longitude pair;
+* Easily converted from/to many different representations (arrays, hashes,
+  degrees/minutes/seconds, radians, strings with different formatting);
+* Geodesy math (distances, directions, endpoints) via precise Vincenty
+  formula.
+
+## Reasons
+
+Geo coordinates are, in fact, one of basic types in XXI century programming.
+
+This gem is a (desperate) attempt to provide such a "basic" type ready
+to be dropped into any of Ruby code, to unify all different `LatLng` or
+`Point` or `Location` classes in existing geography and geo-aware gems
+for easy data exchange and natural usage.
+
+As an independent gem, this attempt is doomed by design, but why not
+to try?..
+
+Initially, I've done this work as a proposal for inclusion in Ruby's
+standard library, but it was not met very well.
+So, now I'm releasing it as a gem to be available at least for my own
+other projects.
+
+You can read my initial proposal [here](https://github.com/zverok/geo_coord/blob/master/StdlibProposal.md)
+and discussion in Ruby tracker [there](https://bugs.ruby-lang.org/issues/12361).
+
+I still have a small hope it would be part of stdlib once, that's why I
+preserve the style of specs (outdated rspec, but compatible with mspec used
+for standard library) and docs (yard in RDoc-compatibility mode).
+
+## Design decisions
+
+While designing `Geo` library, my reference point was standard `Time`
+class (and, to lesser extent, `Date`/`DateTime`). It has these
+responsibilities:
+* stores data in simple internal form;
+* helps to parse and format data to and from strings;
+* provides easy access to logical components of data;
+* allows most simple and unambiguous calculations.
+
+**Namespace name**: The gem takes pretty short and generic top-level
+namespace name `Geo`, but creates only one class inside it: `Geo::Coord`.
+
+**Main type name**: as far as I can see, there's no good singular name
+for `(lat, lng)` pair concept. In different libraries, there can be seen
+names like `LatLng`, or `Location`, or `Point`; and in natural language
+just "coordinates" used frequently. I propose the name `Coord`, which
+is pretty short, easy to remember, demonstrates intentions (and looks
+like singular, so you can have "one coord object" and "array of coords",
+which is not 100% linguistically correct, yet convenient). Alternative
+`Point` name seems to be too ambiguous, being used in many contexts.
+
+`Geo::Coord` object is **immutable**, there's no semantical sense in
+`location.latitude = ...` or something like this.
+
+**Units**: `Geo` calculations (just like `Time` calculations) provide
+no units options, just returning numbers measured in "default" units:
+metres for distances (as they are SI unit) and degrees for azimuth.
+Latitude and longitude are stored in degrees, but radians values accessors
+are provided (being widely used in geodesy math).
+
+All coordinates and calculations are thought to be in
+[WGS 84](https://en.wikipedia.org/wiki/World_Geodetic_System#A_new_World_Geodetic_System:_WGS_84)
+coordinates reference system, being current standard for maps and GPS.
+
+There's introduced **a concept of globe** used internally for calculations.
+Only generic (sphere) and Earth globes are implemented, but for 2016 I
+feel like the current design of basic types should take in consideration
+possibility of writing Ruby scripts for Mars maps analysis. Only one
+geodesy formula is implemented (Vincenty, generally considered one of
+the most precise), as for standard library class it considered
+unnecessary to provide a user with geodesy formulae options.
+
+No **map projection** math was added into the current gem, but it
+may be a good direction for further work. No **elevation** data considered
+either.
+
+## Installation
+
+Now when it is a gem, just do your usual `gem install geo_coord` or add
+`gem "geo_coord"` to your Gemfile.
+
+## Usage
+
+### Creation
+
+```ruby
+# From lat/lng pair:
+g = Geo::Coord.new(50.004444, 36.231389)
+# => #<Geo::Coord 50.004444,36.231389>
+
+# Or using keyword arguments form:
+g = Geo::Coord.new(lat: 50.004444, lng: 36.231389)
+# => #<Geo::Coord 50.004444,36.231389>
+
+# Keyword arguments also allow creation of Coord from components:
+g = Geo::Coord.new(latd: 50, latm: 0, lats: 16, lath: 'N', lngd: 36, lngm: 13, lngs: 53, lngh: 'E')
+# => #<Geo::Coord 50.004444,36.231389>
+```
+
+For parsing API responses you'd like to use `from_h`,
+which accepts String and Symbol keys, any letter case,
+and knows synonyms (lng/lon/longitude):
+
+```ruby
+g = Geo::Coord.from_h('LAT' => 50.004444, 'LON' => 36.231389)
+# => #<Geo::Coord 50.004444,36.231389>
+```
+
+For math, you'd probably like to be able to initialize
+Coord with radians rather than degrees:
+
+```ruby
+g = Geo::Coord.from_rad(0.8727421884291233, 0.6323570306208558)
+# => #<Geo::Coord 50.004444,36.231389>
+```
+
+There's also family of string parsing methods, with different
+applicability:
+
+```ruby
+# Tries to parse (lat, lng) pair:
+g = Geo::Coord.parse_ll('50.004444, 36.231389')
+# => #<Geo::Coord 50.004444,36.231389>
+
+# Tries to parse degrees/minutes/seconds:
+g = Geo::Coord.parse_dms('50° 0′ 16″ N, 36° 13′ 53″ E')
+# => #<Geo::Coord 50.004444,36.231389>
+
+# Tries to do best guess:
+g = Geo::Coord.parse('50.004444, 36.231389')
+# => #<Geo::Coord 50.004444,36.231389>
+g = Geo::Coord.parse('50° 0′ 16″ N, 36° 13′ 53″ E')
+# => #<Geo::Coord 50.004444,36.231389>
+
+# Allows user to provide pattern:
+g = Geo::Coord.strpcoord('50.004444, 36.231389', '%lat, %lng')
+# => #<Geo::Coord 50.004444,36.231389>
+```
+
+[Pattern language description](http://www.rubydoc.info/gems/geo_coord/Geo/Coord#strpcoord-class_method)
+
+### Examining the object
+
+Having Coord object, you can get its properties:
+
+```ruby
+g = Geo::Coord.new(50.004444, 36.231389)
+g.lat # => 50.004444
+g.latd # => 50 -- latitude degrees
+g.lath # => N -- latitude hemisphere
+g.lngh # => E -- longitude hemishpere
+g.phi  # => 0.8727421884291233 -- longitude in radians
+g.latdms # => [50, 0, 15.998400000011316, "N"]
+# ...and so on
+```
+
+### Formatting and converting
+
+```ruby
+g.to_s # => "50.004444,36.231389"
+g.strfcoord('%latd°%latm′%lats″%lath %lngd°%lngm′%lngs″%lngh')
+# => "50°0′16″N 36°13′53″E"
+
+g.to_h(lat: 'LAT', lng: 'LON') # => {'LAT'=>50.004444, 'LON'=>36.231389}
+```
+
+### Geodesy math
+
+```ruby
+kharkiv = Geo::Coord.new(50.004444, 36.231389)
+kyiv = Geo::Coord.new(50.45, 30.523333)
+
+kharkiv.distance(kyiv) # => 410211.22377421556
+kharkiv.azimuth(kyiv) # => 279.12614358262067
+kharkiv.endpoint(410_211, 280) # => #<Geo::Coord 50.505975,30.531283>
+```
+
+[Full API Docs](http://www.rubydoc.info/gems/geo_coord)
+
+## Author
+
+[Victor Shepelev](https://zverok.github.io)
+
+## License
+
+[MIT](https://github.com/zverok/geo_coord/blob/master/LICENSE.txt).

data/StdlibProposal.md

@@ -0,0 +1,175 @@
+## Proposal
+
+Add `Geo::Coord` class to Ruby standard library, representing
+`[latitude, longitude]` pair + convenience methods. Add `Geo` standard
+library with additional calculations and convenience methods.
+
+## Rationale
+
+In modern applications, working with geographical coordinates is frequent.
+We propose to think of such coordinates (namely, `latitude, longitude` pair)
+as of "basic" type that should be supported by standard library - the same
+way as we support `Time`/`Date`/`DateTime` instead of having it defined
+by user/gems.
+
+This type is too "small" to be defined by separate gem, so, all of existing
+geo gems (GeoKit, RGeo, GeoRuby, Graticule etc.) define their own
+`LatLng`, or `Location`, or `Point`, whatever.
+
+On other hand, API design for this "small" type is vague enough for all
+those similar types to be incompatible and break small habits and conventions
+when you change from one geo library to another, or try to use several
+simultaneously.
+
+Additionaly, many gems somehow working with geo coordinates (for weather,
+or timezone, or another tasks) generally prefer not to introduce type, and
+just work with `[lat, lng]` array, which is not very convenient, faithfully.
+
+So, having "geo coordinates" functionality in standard library seems
+reasonable and valuable.
+
+## Existing/reference solutions
+
+Ruby:
+
+* [GeoKit::LatLng](http://www.rubydoc.info/github/geokit/geokit/master/Geokit/LatLng);
+* [RGeo::Feature::Point](http://www.rubydoc.info/gems/rgeo/RGeo/Feature/Point)
+  (with several "private" implementation classes); RGeo implements full
+  [OGC Simple Features](https://en.wikipedia.org/wiki/Simple_Features) specification,
+  so, its points have `z` and `m` coordinates, projection and much more;
+* [Graticule::Location](http://www.rubydoc.info/github/collectiveidea/graticule/Graticule/Location)
+  (not strictly a `[lat,lng]` wrapper);
+* [Rosamary::Node](http://www.rubydoc.info/gems/rosemary/0.4.4/Rosemary/Node)
+  (follows naming convention of underlying OpenStreetMap API);
+
+Other sources:
+* Python: [geopy.Point](http://geopy.readthedocs.org/en/latest/#geopy.point.Point);
+* [ElasticSearch](https://www.elastic.co/blog/geo-location-and-search)
+  uses hash with "lat" and "lon" keys;
+* Google Maps [Geocoding API](https://developers.google.com/maps/documentation/geocoding/intro#GeocodingResponses)
+  uses hash with "lat" and "lng" keys;
+* PostGIS: [pretty complicated](http://postgis.net/docs/manual-2.2/using_postgis_dbmanagement.html#RefObject)
+  has _geometrical_ (projected) and _geographical_ (lat, lng) points and
+  stuff.
+
+## Design decisions
+
+While designing `Geo` library, our reference point was standard `Time`
+class (and, to lesser extent, `Date`/`DateTime`). It has this
+responsibilities:
+* stores data in simple internal form;
+* helps to parse and format data to and from strings;
+* provides easy access to logical components of data;
+* allows most simple and unambiguous calculations.
+
+**Main type name**: as far as we can see, there's no good singular name
+for `(lat, lng)` pair concept. As mentioned above, there can be seen
+names like `LatLng`, or `Location`, or `Point`; and in natural language
+just "coordinates" used frequently. We propose the name `Coord`, which
+is pretty short, easy to remember, demonstrates intentions (and looks
+like singular, so you can have "one coord object" and "array of coords",
+which is not 100% linguistically correct, yet convenient). Alternative
+`Point` name seems to be too ambigous, being used in many contexts.
+
+`Geo::Coord` object is **immutable**, there's no semantical sense in
+`location.latitude = ...` or something like this.
+
+**Units**: `Geo` calculations (just like `Time` calculations) provide
+no units options, just returning numbers measured in "default" units:
+metres for distances (as they are SI unit) and degrees for azimuth.
+Latitude and longitude are stored in degrees, but radians values accessors
+are provided (being widely used in geodesy math).
+
+All coordinates and calculations are thought to be in
+[WGS 84](https://en.wikipedia.org/wiki/World_Geodetic_System#A_new_World_Geodetic_System:_WGS_84)
+coordinates reference system, being current standard for maps and GPS.
+
+There's introduced **concept of globe** used internally for calculations.
+Only generic (sphere) and Earth globes are implemented, but for 2016 we
+feel like current design of basic types should take in consideration
+possibility of writing Ruby scripts for Mars maps analysis. Only one
+geodesy formula is implemented (Vincenty, generally considered one of
+the most precise), as for standard library class it considered
+unnecessary to provide user with geodesy formulae options.
+
+No **map projection** math was added into current proposal, but it
+may be a good direction for further work. No **elevation** data considered
+either.
+
+## Proposal details
+
+### `Geo::Coord` class
+
+Represents `[latitude, longitude]` pair. Latitude is -90 to +90 (degrees).
+Longitude is -180 to +180.
+
+Class methods:
+* `new(lat, lng)` creates instance from two Numerics (in degrees);
+* `new(lat:, lng:)` keyword arguments form of above;
+* `new(latd:, latm:, lats:, lath:, lngd: lngm:, lngs: lngh:)` creates
+  instance from coordinates in (deg, min, sec, hemisphere) form; hemispheres
+  are "N"/"S" for latitude and "W"/E" for longitude; any component except
+  for degrees can be omitted; if hemisphere is omitted, it is decided by
+  degrees sign (lat: positive is "N", lng: positive is "E");
+* `from_h(hash)` creates instance from hash with `"lat"` or `"latitude"`
+  key and `"lon"` or `"lng"` or `"longitude"` key (case-independent);
+* `from_radians(phi, la)` creates instance from radian values;
+* `strpcoord` parses string into coordinates by provided pattern (see
+  below for pattern description);
+* `parse_ll` parses coordinates string in `"float, float"` form;
+* `parse_dms` parses coordinates string in `d m s h, d m s h` format
+  (considering several widely used symbols for degrees, minutes and seconds);
+* `parse` tries to parse string into coordinates from various formats.
+
+Instance methods:
+* `lat` and `lng`, returning `Float`s, signed;
+* `latitude` and `longitude` as an aliases; `lon` as an additional
+  aliases for longitude;
+* `latd`, `latm`, `lats`, `lath`: degree, minute, second, hemisphere;
+  `latd` and `latm` are `Fixnum`, `lats` is `Float`, `lath` is "N"/"S"; all
+  numbers are unsigned;
+* `lngd`, `lngm`, `lngs`, `lngh`: the same for longitude (hemisphere is
+  "W"/"E");
+* `latdms(nohemisphere = false)` returns `[latd, latm, lats, lath]` with
+  `nohemisphere` param equal to `false`, and `[±latd, latm, lats]` with
+  `true`; same with `lngdms` for longitude;
+* `phi` and `φ` is latitude in radians (helpful for math), `la` or `λ`
+  is longitude in radians (not `lambda` to not confuse with Kernel method);
+* `to_s` returning string like "50.004444,36.231389" (good for map
+  URLs construction, for example);
+* `to_h(lat: :lat, lng: :lng)` converts coord to hash (with
+  desired key names);
+* `to_a` converts coord to simple `[lat, lng]` pair;
+* `strfcoord(formatstr)` for complex coordinate formatting (see below
+  for format string description);
+* `distance(other)` calculates distance to another point (in metres);
+* `azimuth(other)` calculates direction to target (in degrees);
+* `endpoint(direction, azimuth)` calculates final point of the line of
+  `distance` metres going in `azimuth` direction from current point.
+
+#### `strpcoord`/`strfcoord`
+
+Example:
+```ruby
+kharkiv.strfcoord('%latdu°%latm′%lats″ %lath, %lngdu°%lngm′%lngs″ %lngh')
+# => "50°0′16″ N, 36°13′53″ E"
+```
+
+Directives:
+* `%lat` - full latitude, float; can be formatted with more control like
+  `%.4lat` (four digits after point) or `%+lat` (explicit plus sign for
+  positive latitudes);
+* `%latd` - latitude degrees, unsigned, integer
+* `%latds` - latitude degrees, signed
+* `%latm` - latitude minutes, unsigned, integer
+* `%lats` - latitude seconds, unsigned, integer, but can be formatted as
+  float: `%.2lats`
+* `%lath` - latitude hemisphere, one letter ("N"/"S")
+* `%lng`, `%lngd`, `%lngds`, `%lngs`, `%lngh`, `%lngH` - same for longitude
+* `%%` literal `%` sign
+
+### Current implementation
+
+Proposed implementation can be found at https://github.com/zverok/geo_coord.
+It was created with thoughts of standard library, so, all docs are in
+RDoc format, and tests/specs are in mspec-compatible rspec flavour.

data/geo_coord.gemspec

@@ -0,0 +1,38 @@
+require './lib/geo/coord/version'
+
+Gem::Specification.new do |s|
+  s.name     = 'geo_coord'
+  s.version  = Geo::Coord::VERSION
+  s.authors  = ['Victor Shepelev']
+  s.email    = 'zverok.offline@gmail.com'
+  s.homepage = 'https://github.com/zverok/geo_coord'
+
+  s.summary = 'Geo::Coord class'
+  s.description = <<-EOF
+  EOF
+  s.licenses = ['MIT']
+
+  s.files = `git ls-files`.split($RS).reject do |file|
+    file =~ /^(?:
+    spec\/.*
+    |Gemfile
+    |Rakefile
+    |\.rspec
+    |\.gitignore
+    |\.rubocop.yml
+    |\.travis.yml
+    )$/x
+  end
+  s.require_paths = ["lib"]
+
+  s.required_ruby_version = '>= 2.1.0'
+
+  s.add_development_dependency 'rubocop', '>= 0.40'
+  s.add_development_dependency 'rspec', '= 2.14'
+  s.add_development_dependency 'mspec'
+  s.add_development_dependency 'simplecov', '~> 0.9'
+  s.add_development_dependency 'rake'
+  s.add_development_dependency 'rubygems-tasks'
+  s.add_development_dependency 'yard'
+  s.add_development_dependency 'coveralls'
+end

data/lib/geo/coord/globes.rb

@@ -0,0 +1,165 @@
+require 'singleton'
+
+module Geo
+  # @private
+  module Coord::Globes # :nodoc:all
+    # Notes on this module
+    #
+    # **Credits:**
+    #
+    # Most of the initial code/algo, as well as tests were initially borrowed from
+    # [Graticule](https://github.com/collectiveidea/graticule).
+    #
+    # Algo descriptions borrowed from
+    #
+    # * http://www.movable-type.co.uk/scripts/latlong.html (simple)
+    # * http://www.movable-type.co.uk/scripts/latlong-vincenty.html (Vincenty)
+    #
+    # **On naming and code style:**
+    #
+    # Two main methods (distance/azimuth between two points and endpoint by
+    # startpoint and distance/azimuth) are named `inverse` & `direct` due
+    # to solving "two main geodetic problems": https://en.wikipedia.org/wiki/Geodesy#Geodetic_problems
+    #
+    # Code for them is pretty "un-Ruby-ish", trying to preserve original
+    # formulae as much as possible (including use of Greek names and
+    # inconsistent naming of some things: "simple" solution of direct problem
+    # names distance `d`, while Vincenty formula uses `s`).
+    #
+    class Generic
+      include Singleton
+      include Math
+
+      def inverse(phi1, la1, phi2, la2)
+        # See http://www.movable-type.co.uk/scripts/latlong.html
+        delta_phi = phi2 - phi1
+        delta_la = la2 - la1
+        a = sin(delta_phi/2)**2 + cos(phi1)*cos(phi2) * sin(delta_la/2)**2
+        c = 2 * atan2(sqrt(a), sqrt(1-a))
+        d = r * c
+
+        y = sin(delta_la) * cos(phi1)
+        x = cos(phi1) * sin(phi2) - sin(phi1) * cos(phi2) * cos(delta_la)
+
+        a = atan2(y, x)
+
+        [d, a]
+      end
+
+      def direct(phi1, la1, d, alpha1)
+        phi2 = asin( sin(phi1)*cos(d/r) +
+                    cos(phi1)*sin(d/r)*cos(alpha1) )
+        la2 = la1 + atan2(sin(alpha1)*sin(d/r)*cos(phi1), cos(d/r)-sin(phi1)*sin(phi2))
+        [phi2, la2]
+      end
+
+      private
+
+      def r
+        self.class::RADIUS
+      end
+    end
+
+    class Earth < Generic
+      # All in SI units (metres)
+      RADIUS = 6378135
+      MAJOR_AXIS = 6378137
+      MINOR_AXIS = 6356752.3142
+      F = (MAJOR_AXIS - MINOR_AXIS) / MAJOR_AXIS
+
+      VINCENTY_MAX_ITERATIONS = 20
+      VINCENTY_TOLERANCE = 1e-12
+
+      def inverse(phi1, la1, phi2, la2)
+        # Vincenty formula
+        # See http://www.movable-type.co.uk/scripts/latlong-vincenty.html
+        l = la2 - la1
+        u1 = atan((1-F) * tan(phi1))
+        u2 = atan((1-F) * tan(phi2))
+        sin_u1 = sin(u1); cos_u1 = cos(u1)
+        sin_u2 = sin(u2); cos_u2 = cos(u2)
+
+        la = l # first approximation
+        la_, cosSqalpha, sin_sigma, cos_sigma, sigma, cos2sigmaM, sinla, cosla = nil
+
+        VINCENTY_MAX_ITERATIONS.times do
+          sinla = sin(la)
+          cosla = cos(la)
+
+          sin_sigma = sqrt((cos_u2*sinla) * (cos_u2*sinla) +
+            (cos_u1*sin_u2-sin_u1*cos_u2*cosla) * (cos_u1*sin_u2-sin_u1*cos_u2*cosla))
+
+          return [0, 0] if sin_sigma == 0  # co-incident points
+
+          cos_sigma = sin_u1*sin_u2 + cos_u1*cos_u2*cosla
+          sigma = atan2(sin_sigma, cos_sigma)
+          sinalpha = cos_u1 * cos_u2 * sinla / sin_sigma
+          cosSqalpha = 1 - sinalpha*sinalpha
+          cos2sigmaM = cos_sigma - 2*sin_u1*sin_u2/cosSqalpha
+          cos2sigmaM = 0 if cos2sigmaM.nan?  # equatorial line: cosSqalpha=0 (§6)
+
+          c = F/16*cosSqalpha*(4+F*(4-3*cosSqalpha))
+          la_ = la
+          la = l + (1-c) * F * sinalpha *
+            (sigma + c*sin_sigma*(cos2sigmaM+c*cos_sigma*(-1+2*cos2sigmaM*cos2sigmaM)))
+
+          break if la_ && (la - la_).abs < VINCENTY_TOLERANCE
+        end
+
+        # Formula failed to converge (happens on antipodal points)
+        # We'll call Haversine formula instead.
+        return super if (la - la_).abs > VINCENTY_TOLERANCE
+
+        uSq = cosSqalpha * (MAJOR_AXIS**2 - MINOR_AXIS**2) / (MINOR_AXIS**2)
+        a = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)))
+        b = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)))
+        delta_sigma = b*sin_sigma*(cos2sigmaM+b/4*(cos_sigma*(-1+2*cos2sigmaM*cos2sigmaM)-
+          b/6*cos2sigmaM*(-3+4*sin_sigma*sin_sigma)*(-3+4*cos2sigmaM*cos2sigmaM)))
+
+        s = MINOR_AXIS * a * (sigma-delta_sigma)
+        alpha1 = atan2(cos_u2*sinla, cos_u1*sin_u2 - sin_u1*cos_u2*cosla)
+
+        [s, alpha1]
+      end
+
+      def direct(phi1, la1, s, alpha1)
+        sinalpha1 = sin(alpha1)
+        cosalpha1 = cos(alpha1)
+
+        tanU1 = (1-F) * tan(phi1)
+        cosU1 = 1 / sqrt(1 + tanU1**2)
+        sinU1 = tanU1 * cosU1
+        sigma1 = atan2(tanU1, cosalpha1)
+        sinalpha = cosU1 * sinalpha1
+        cosSqalpha = 1 - sinalpha**2
+        uSq = cosSqalpha * (MAJOR_AXIS**2 - MINOR_AXIS**2) / (MINOR_AXIS**2);
+        a = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)))
+        b = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)))
+
+        sigma = s / (MINOR_AXIS*a)
+        sigma_ = nil
+
+        begin
+            cos2sigmaM = cos(2*sigma1 + sigma);
+            sinsigma = sin(sigma);
+            cossigma = cos(sigma);
+            delta_sigma = b*sinsigma*(cos2sigmaM+b/4*(cossigma*(-1+2*cos2sigmaM**2)-
+                b/6*cos2sigmaM*(-3+4*sinsigma**2)*(-3+4*cos2sigmaM**2)))
+            sigma_ = sigma
+            sigma = s / (MINOR_AXIS*a) + delta_sigma
+        end while (sigma-sigma_).abs > 1e-12
+
+        tmp = sinU1*sinsigma - cosU1*cossigma*cosalpha1
+        phi2 = atan2(sinU1*cossigma + cosU1*sinsigma*cosalpha1, (1-F)*sqrt(sinalpha**2 + tmp**2))
+        la = atan2(sinsigma*sinalpha1, cosU1*cossigma - sinU1*sinsigma*cosalpha1)
+        c = F/16*cosSqalpha*(4+F*(4-3*cosSqalpha))
+        l = la - (1-c) * F * sinalpha *
+            (sigma + c*sinsigma*(cos2sigmaM+c*cossigma*(-1+2*cos2sigmaM*cos2sigmaM)))
+
+        la2 = (la1+l+3*PI) % (2*PI) - PI # normalise to -PI...+PI
+
+        [phi2, la2]
+      end
+    end
+  end
+end

data/lib/geo/coord/version.rb

@@ -0,0 +1,5 @@
+module Geo
+  class Coord
+    VERSION = '0.0.1'.freeze
+  end
+end