Encoded polylines vs Polyline class

[Chris Apolzon]

I'm working on a project where we'll be rendering a large number of
polylines and polygons, and I was curious if any of the core
developers could chime in on performance differences between using
encoded polylines and the new polyline/polygon classes? I thought
maybe encoded polylines had gone the way of the dodo, but I noticed
Esa comment on a v2 thread that the Directions class is using encoded
polylines.
(Or if anyone has any horror stories of why I shouldn't even consider
encoded polylines that would be welcome as well!)
Thanks!

[Chris Apolzon]

I suppose I should add I'm primarily interested in the ability to use
the encoding levels. I thought v3 did something like this out of the
box, but I haven't found any firm confirmation of that. (See
http://googlegeodevelopers.blogspot.com/2009/09/polys-in-maps-api-v3-now-with-level-of.html)

[Ben Appleton]

v3 does this under the hood.  It is optimized for fast rendering of complicated polylines/polygons; we're working to improve rendering of large numbers of polylines/polygons.

--
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 google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Chris Apolzon]

I'm wondering if I can speed up my map by passing a pre-encoded
polyline into the polyline constructor instead of letting google
encode it. I haven't seen anything in the v3 documentation about
forcing the use of an encoded polyline, is there a workaround to allow
this to happen? I'd be fine abandoning the polyline class if
necessary.

On Jan 5, 6:35 pm, Ben Appleton <apple...@google.com> wrote:
> v3 does this under the hood.  It is optimized for fast rendering of
> complicated polylines/polygons; we're working to improve rendering of large
> numbers of polylines/polygons.
>
>
>
> On Wed, Jan 6, 2010 at 4:35 AM, Chris Apolzon <apol...@gmail.com> wrote:
> > I suppose I should add I'm primarily interested in the ability to use
> > the encoding levels.  I thought v3 did something like this out of the
> > box, but I haven't found any firm confirmation of that.  (See
>

> >http://googlegeodevelopers.blogspot.com/2009/09/polys-in-maps-api-v3-...

> > )
>
> > On Jan 5, 12:32 pm, Chris Apolzon <apol...@gmail.com> wrote:
> > > I'm working on a project where we'll be rendering a large number of
> > > polylines and polygons, and I was curious if any of the core
> > > developers could chime in on performance differences between using
> > > encoded polylines and the new polyline/polygon classes?  I thought
> > > maybe encoded polylines had gone the way of the dodo, but I noticed
> > > Esa comment on a v2 thread that the Directions class is using encoded
> > > polylines.
> > > (Or if anyone has any horror stories of why I shouldn't even consider
> > > encoded polylines that would be welcome as well!)
> > > Thanks!
>
> > --
> > 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
> > google-map...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-maps-js-a...@googlegroups.com<google-maps-js-api-v3%2B unsub...@googlegroups.com>

[Ben Appleton]

That sounds reasonable, please file a feature request.  Profiling shows that, in some cases, computing level of detail accounts for up to 40% of the initial rendering time (but speeds up subsequent panning and zooming by > 10x).

To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.

[bratliff]

On Jan 12, 6:54 pm, Chris Apolzon <apol...@gmail.com> wrote:
> I'm wondering if I can speed up my map by passing a pre-encoded
> polyline into the polyline constructor instead of letting google
> encode it. I haven't seen anything in the v3 documentation about
> forcing the use of an encoded polyline, is there a workaround to allow
> this to happen? I'd be fine abandoning the polyline class if
> necessary.

I have several large poly demos running at:

http://www/polyarc.us/polycluster

for both API V2 & API V3.

The compression algorithm is different than the one used by Google.
It is pixel based for full precision at deep zoom levels. Point
reduction is done on the fly. "zoom strings" are not required nor
useful resulting in a reduction in the size of the poly definition
package. It also eliminates a lot of confusion.

It works in any browser supporting either CANVAS or SVG. I am still
trying to make VML (the rendering engine used by Internet Explorer)
work, but, thanks to Ben, I have an example I ought to be able to
adapt.

[bratliff]

On Jan 13, 6:44 am, bratliff <bratl...@umich.edu> wrote:

OOPS, bad URL Try:

http://www.polyarc.us/polycluster

[Chris Apolzon]

I'm quite impressed by the speed of your demos.  Is your polycluster js file open source?  Do you have any documentation or can I peek at the unobfuscated source?

--
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 google-map...@googlegroups.com.

To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.