Lat, Lng vs Lng, Lat

[astjohn]

Hi there,

Thanks for this wonderful library. I realize that google's algorithm anticipates latitude/longitude pairing. However, most pairings (including geojson data) are usually in the form of [longitude, latitude] or [x,y].

Does it make more sense for this gem's api to accept [longitude, latitude] pairings so that users can almost pump straight geojson data into it? This would make things much more convenient.

[joshuaclayton]

@astjohn I don't think it makes sense to - even though their order is [long, lat], I've always gone off of others' (including Google's) description of them as LatLngs. From the geojson, you should be able to just call list_of_lng_lats.map(&:reverse).

[astjohn]

@joshuaclayton - That will be a very expensive operation though if the geojson has thousands of points in it.

[joshuaclayton]

@astjohn any ideas on number of points for the geojson?

I threw together a quick benchmark for time to reverse all the items in the array and the time to encode the array to a polyline, and the results (locally on a 2013 2.6GHz i7 MBP) were:

Time to reverse: 63.010062993271276ms
Time to encode: 7701.452592998976ms

This was for 500,000 lng/lat pairs.

Here's what I'd used to benchmark:

require "benchmark"
require "polylines"

def generate_lng_lat_pair
  [
    (rand(360) - 180) + rand,
    (rand(180) - 90) + rand
  ]
end

POINTS = 500_000

to_reverse = POINTS.times.map { generate_lng_lat_pair }
reversed = []

time = Benchmark.realtime do
  reversed = to_reverse.map &:reverse
end

puts "Time to reverse: #{time * 1000}ms"

poly_time = Benchmark.realtime do
  Polylines::Encoder.encode_points(reversed)
end

puts "Time to encode: #{poly_time * 1000}ms"

All that said, if 500,000 pairs is actually not an uncommon number of points, I do think we may want to speed up the encoding time as 7.7s is a fairly long time (long enough these calculations would have to happen in a background job).