Skip Menu |

This queue is for tickets about the Algorithm-GooglePolylineEncoding CPAN distribution.

Report information
The Basics
Id: 74303
Status: resolved
Priority: 0/
Queue: Algorithm-GooglePolylineEncoding

People
Owner: Nobody in particular
Requestors: jidanni [...] jidanni.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: srezic [...] cpan.org
Subject: worse roundtrip performance
Date: Tue, 24 Jan 2012 14:33:08 +0800
To: bug-Algorithm-GooglePolylineEncoding [...] rt.cpan.org
From: jidanni [...] jidanni.org
Doing some roundtrip tests, it seems some tightening up is needed. Enclosed is a test program. $VERSION = '0.02';

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #74303] AutoReply: worse roundtrip performance
Date: Tue, 24 Jan 2012 14:42:15 +0800
To: bug-algorithm-googlepolylineencoding [...] rt.cpan.org
From: jidanni [...] jidanni.org
On 2012-01-24 01:42:25, jidanni@jidanni.org wrote: Show quoted text
> Most of it I hacked from http://www.usnaviguide.com/google-encode.htm .
Can you try out the patched version: git clone git://github.com/eserte/algorithm-googlepolylineencoding.git -b RT74303 With my sample kml files there are no more differences to the other algorithm. Regards, Slaven
Subject: Re: [rt.cpan.org #74303] worse roundtrip performance
Date: Wed, 25 Jan 2012 13:32:29 +0800
To: bug-algorithm-googlepolylineencoding [...] rt.cpan.org
From: jidanni [...] jidanni.org
Years ago I removed git. I will have to wait until it is installable with cpanminus to test.
Subject: Re: [rt.cpan.org #74303] worse roundtrip performance
Date: Wed, 25 Jan 2012 08:09:18 +0100
To: bug-Algorithm-GooglePolylineEncoding [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Dan Jacobson via RT" <bug-Algorithm-GooglePolylineEncoding@rt.cpan.org> writes: Show quoted text
> Queue: Algorithm-GooglePolylineEncoding > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=74303 > > > Years ago I removed git. > I will have to wait until it is installable with cpanminus to test. >
Here's a patch: diff --git a/GooglePolylineEncoding.pm b/GooglePolylineEncoding.pm index 0d3fef3..14df217 100644 --- a/GooglePolylineEncoding.pm +++ b/GooglePolylineEncoding.pm @@ -72,14 +72,13 @@ sub encode_number { sub encode_polyline { my(@path) = @_; my @res; - my($curr_lat,$curr_lon) = do { my $first = shift @path; ($first->{lat}, $first->{lon}) }; - push @res, encode_number($curr_lat), encode_number($curr_lon); + my($curr_lat_e5,$curr_lon_e5) = (0,0); for my $lat_lon (@path) { - my($lat,$lon) = ($lat_lon->{lat}, $lat_lon->{lon}); - my $deltay = $lat - $curr_lat; - my $deltax = $lon - $curr_lon; + my($lat_e5,$lon_e5) = map { sprintf("%.0f", $_*1e5) } ($lat_lon->{lat}, $lat_lon->{lon}); + my $deltay = ($lat_e5 - $curr_lat_e5) / 1e5; + my $deltax = ($lon_e5 - $curr_lon_e5) / 1e5; push @res, encode_number($deltay), encode_number($deltax); - ($curr_lat,$curr_lon) = ($lat,$lon); + ($curr_lat_e5,$curr_lon_e5) = ($lat_e5,$lon_e5); } join '', @res; } -- Slaven Rezic - slaven <at> rezic <dot> de BBBike - route planner for cyclists in Berlin WWW version: http://www.bbbike.de Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
CC: undisclosed-recipients:;
Subject: Re: [rt.cpan.org #74303] worse roundtrip performance
Date: Wed, 25 Jan 2012 08:09:09 +0100
To: bug-Algorithm-GooglePolylineEncoding [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Dan Jacobson via RT" <bug-Algorithm-GooglePolylineEncoding@rt.cpan.org> writes: Show quoted text
> Queue: Algorithm-GooglePolylineEncoding > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=74303 > > > Years ago I removed git. > I will have to wait until it is installable with cpanminus to test. >
Here's a patch: diff --git a/GooglePolylineEncoding.pm b/GooglePolylineEncoding.pm index 0d3fef3..14df217 100644 --- a/GooglePolylineEncoding.pm +++ b/GooglePolylineEncoding.pm @@ -72,14 +72,13 @@ sub encode_number { sub encode_polyline { my(@path) = @_; my @res; - my($curr_lat,$curr_lon) = do { my $first = shift @path; ($first->{lat}, $first->{lon}) }; - push @res, encode_number($curr_lat), encode_number($curr_lon); + my($curr_lat_e5,$curr_lon_e5) = (0,0); for my $lat_lon (@path) { - my($lat,$lon) = ($lat_lon->{lat}, $lat_lon->{lon}); - my $deltay = $lat - $curr_lat; - my $deltax = $lon - $curr_lon; + my($lat_e5,$lon_e5) = map { sprintf("%.0f", $_*1e5) } ($lat_lon->{lat}, $lat_lon->{lon}); + my $deltay = ($lat_e5 - $curr_lat_e5) / 1e5; + my $deltax = ($lon_e5 - $curr_lon_e5) / 1e5; push @res, encode_number($deltay), encode_number($deltax); - ($curr_lat,$curr_lon) = ($lat,$lon); + ($curr_lat_e5,$curr_lon_e5) = ($lat_e5,$lon_e5); } join '', @res; } -- Slaven Rezic - slaven <at> rezic <dot> de BBBike - route planner for cyclists in Berlin WWW version: http://www.bbbike.de Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
Subject: Re: [rt.cpan.org #74303] worse roundtrip performance
Date: Wed, 25 Jan 2012 15:31:32 +0800
To: bug-algorithm-googlepolylineencoding [...] rt.cpan.org
From: jidanni [...] jidanni.org
Show quoted text
>>>>> "sdvR" == slaven@rezic de via RT <bug-Algorithm-GooglePolylineEncoding@rt.cpan.org> writes:
Show quoted text
sdvR> Here's a patch:
Indeed, now the results are the same as you said! But I still think you can go further and beat all the other algorithms: Given A=Original points B=Rounded to five digits points Then take them for a round trip. Why can't we get back to B, and not just B+-1? Odd, if the input is already 5 digits long, then it comes back intact. Or something like that. OK, I'm not talking very clearly, but maybe you know what I mean.
CC: slaven [...] rezic.de
Subject: Re: [rt.cpan.org #74303] worse roundtrip performance
Date: Sun, 29 Jan 2012 11:59:48 +0800
To: bug-algorithm-googlepolylineencoding [...] rt.cpan.org
From: jidanni [...] jidanni.org
Show quoted text
sdvR> index 0d3fef3..14df217 100644
OK, yes thanks for the patch... But even with it, there is a more basic question I would like to ask first: #!/usr/bin/perl ## Let's make use Algorithm::GooglePolylineEncoding; ## give the best roundtrip results possible! ## I would like to ask even before going on roundtrips, why can't the ## algorithm produce the same string when given instead a rounded ## version of the input? ## Test with ## $ perl thisfile somefile.kml use strict; use warnings FATAL => 'all'; my @names = qw/original rounded/; my %polyline; while (<>) { if (/([0-9.]+),([0-9.]+)/) { push @{ $polyline{original} }, { lat => $2, lon => $1 }; push @{ $polyline{rounded} }, { lat => ( sprintf "%.5f", $2 ), lon => ( sprintf "%.5f", $1 ) }; ##Correct, no? } } my %encoded_polyline; for (@names) { $encoded_polyline{$_} = Algorithm::GooglePolylineEncoding::encode_polyline( @{ $polyline{$_} } ); print $encoded_polyline{$_}, "\n"; } for ( split //, $encoded_polyline{ $names[0] } ^ $encoded_polyline{ $names[1] } ) { use feature "switch"; given ($_) { when ("\0") { print "_" } default { print "X"; } } }
CC: bug-algorithm-googlepolylineencoding [...] rt.cpan.org
Subject: Re: [rt.cpan.org #74303] forget sprintf
Date: Sat, 04 Feb 2012 01:40:41 +0800
To: srezic [...] cpan.org, slaven [...] rezic.de
From: jidanni [...] jidanni.org
$ perldoc -q \ round mentions half-way-point alternation... so forget all my sprintf stuff. Your way is better! OK, maybe there is no more roundtrip problem. #!/usr/bin/perl use strict; use warnings FATAL => 'all'; use Algorithm::GooglePolylineEncoding; my @encoded_polyline; my @decoded_polyline; while (<>) { if (/([0-9.]+),([0-9.]+)/) { push @{ $decoded_polyline[0] }, { lat => $2, lon => $1 }; } } for ( 0 .. 2 ) { $encoded_polyline[$_] = Algorithm::GooglePolylineEncoding::encode_polyline( @{ $decoded_polyline[$_] } ); print $encoded_polyline[$_], "\n"; @{ $decoded_polyline[ $_ + 1 ] } = Algorithm::GooglePolylineEncoding::decode_polyline( $encoded_polyline[$_] ); } for (@encoded_polyline) { use Digest::MD5 qw(md5 md5_hex md5_base64); print md5_hex($_), "\n"; }