To encode or not - an example

[mark mcclure]

I've seen several discussions on this list asking whether encoded
polylines/polygons will ever be included in the V3 API. While I
certainly think that the auto-encoding on the fly that is now built
into the new API is a great addition, I still think that the option to
pre-encode delivers the greatest performance. Here's a natural
example.
V2 pre-encoded:
http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/BritishCoastline.html
V3 auto-encoded:
http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/gmap3.html

It should be no surprise that the first loads faster, since it much
smaller. Even after the page loads, however, there is a delay in the
second where, presumably, the encoding occurs.

FWIW,
Mark McClure

[bratliff]

On Jun 28, 3:45 am, mark mcclure <mcmcc...@unca.edu> wrote:
> I've seen several discussions on this list asking whether encoded
> polylines/polygons will ever be included in the V3 API. While I
> certainly think that the auto-encoding on the fly that is now built
> into the new API is a great addition, I still think that the option to
> pre-encode delivers the greatest performance. Here's a natural
> example.

> V2 pre-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/BritishCo...

> V3 auto-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/gmap3.html
>
> It should be no surprise that the first loads faster, since it much
> smaller. Even after the page loads, however, there is a delay in the
> second where, presumably, the encoding occurs.
>
> FWIW,
> Mark McClure

Other factors contribute to the performance difference. V2 builds a
single rectangular DIV. V3 builds tiles. A single rectangular DIV is
quick to initialize but panning & zooming are slow. Tiles require
extra effort to construct but panning & zooming are fast. V2 accepts
an array of {x:,y:} objects which is directly executable in
JavaScript. V3 requires every vertex to be executed in a new LatLng
object constructor which adds a ridiculous amount of overhead. Except
for reduced file size & reduced transmission time, encoding does not
offer very much. Zoom strings are an abomination.

http://www.polyarc.us

contains several demos of like complexity. I will try to duplicate
your British coast line demo in the next several days.

[William]

On Jun 28, 1:45 pm, mark mcclure <mcmcc...@unca.edu> wrote:
> It should be no surprise that the first loads faster, since it much
> smaller.  

the first loads the encoded coastline in a separate 200KB javascript,
and the second has the data within the 2 megabyte html file. If gzip
compression was enabled on the web server, then the download for the
second would be near to 300KB instead of 2 megabytes, and the two
pages would load in similar times.

[bratliff]

Space could be saved with something like:

var p=
{
x:[lng0,lng1, ... ]
,
y:[lat0.lat1, ... ]
}
;

var path=[];

for (var i=0;(p.x[i]!=null)*(p.y[i]!=null);i++)
{
path[i]=new google.maps.LatLng(p.y[i],p.x[i]);
}

Of course, Google could support such a structure directly for a huge
reduction in overhead. I submitted a suggestion to the issue
tracker. It was rejected.

[bratliff]

On Jun 28, 3:45 am, mark mcclure <mcmcc...@unca.edu> wrote:

> I've seen several discussions on this list asking whether encoded
> polylines/polygons will ever be included in the V3 API. While I
> certainly think that the auto-encoding on the fly that is now built
> into the new API is a great addition, I still think that the option to
> pre-encode delivers the greatest performance. Here's a natural
> example.

> V2 pre-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/BritishCo...

> V3 auto-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/gmap3.html
>
> It should be no surprise that the first loads faster, since it much
> smaller. Even after the page loads, however, there is a delay in the
> second where, presumably, the encoding occurs.
>
> FWIW,
> Mark McClure

I have posted two additional demos. Both use PolyCluster, a light
weight polyline / polygon facility. It supports compression. It is
tile based for quick dragging / panning / zooming. It performs "on-
the-fly" point reduction without "levels" zoom strings.

Standard

http://www.polyarc.us/polycluster/coast/standard.html

Compressed

http://www.polyarc.us/polycluster/coast/compress.html

Cache content, browser, CPU speed, connection / transmission speed,
etc. each contribute to the differences.

[bratliff]

On Jun 28, 3:45 am, mark mcclure <mcmcc...@unca.edu> wrote:

> I've seen several discussions on this list asking whether encoded
> polylines/polygons will ever be included in the V3 API. While I
> certainly think that the auto-encoding on the fly that is now built
> into the new API is a great addition, I still think that the option to
> pre-encode delivers the greatest performance. Here's a natural
> example.

> V2 pre-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/BritishCo...

> V3 auto-encoded:http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/gmap3.html
>
> It should be no surprise that the first loads faster, since it much
> smaller. Even after the page loads, however, there is a delay in the
> second where, presumably, the encoding occurs.
>
> FWIW,
> Mark McClure

I have added another demo with your encoded points:

http://www.polyarc.us/polycluster/coast/encoded.html

I have run some tests. I do agree with you. For very large polys,
some form of compression does help. Eliminating the requirement to
construct a new LatLng object for every vertex also helps.