On Jun 28, 3:45 am, mark mcclure <[email protected]> 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.
--
You received this message because you are subscribed to the Google Groups
"Google Maps JavaScript API v3" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
