Building complicated polylines with multiple colors in multiple directions

[Jasperdc]

Hello,

I'm currently trying to figure out how I can show traffic information
in an overlay on a Google Map (in a country where google maps does not
already support Live Traffic). The provided data looks like: "point a
to point b is red" but the problem is that I've got approx. 2000 of
these small lines, this causes the browser to crash/timeout due to the
long render time (obviously) when adding them to the map one by one.

Now I was wondering if encoded polygon lines are really the way to go
here... maybe I could group by color so I would have 3 encoded poly
line objects (e.g. green,orange,red,...). The problem in this case is
that the highways obviously head in multiple directions, which makes
it impossible to define in a single polyline (as far as I know).

So my final question would be:
Does anyone have experience with drawing complex polylines in multiple
directions with up to about 2000 small parts?

An alternative solution would be to draw all the roads in green by
default and overwrite parts with red/orange where applicable.

Thanks in advance,
Jasper

[Marcelo]

On Feb 15, 12:48 pm, Jasperdc <jasper.de.craec...@gmail.com> wrote:
>
> So my final question would be:
> Does anyone have experience with drawing complex polylines in multiple
> directions with up to about 2000 small parts?

Yes, do the same that Google does: Use custom tiles instead of
polylines:
http://mt0.google.com/vt?hl=en&lyrs=m@118,traffic|seconds_into_week:-1&x=82&y=198&z=9&opts=T

--
Marcelo - http://maps.forum.nu
--

[bratliff]

Look at the "Lake Michigan Shore" demo accessable from:

http://www.polyarc.us

It is a small demo but it scales well. A single OverlayView handles
all polys rather than one OverlayView per poly. A single event
listener handles all dragging, panning & zooming. Polys are defined
in a cluster rather than individually. Polys must have unique names
which are their reference handles.

You can change the color of several polys to the same color with the
"setColor" method.

var polyarray=[polya,polyb,polyc,polyd, ... ];

var
color={fill:,fillColor:,fillAlpha:,stroke:,strokeColor:,strokeAlpha:,weight:};

cluster.setColor(polyarray,color);

[Chris Apolzon]

I ran into this same issue trying to render many complicated polygons and polylines.  I have since migrated my code to use bratliff's polycluster library.  I can't recommend it enough!  And the progress that has been made over the past month has made it even better.

--
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.

[PhilR8]

Berry,

I've been looking over PolyClusters for little while and think it's
great, but I'm having trouble following your examples. They're over
my head. I'd like to do something like what you're talking about, but
with polygons instead of lines: say, three or four arrays of polygons
with different colors. Do you have any documentation other than your
examples page?

[bratliff]

On Feb 25, 8:25 pm, PhilR8 <phi...@gmail.com> wrote:
> Berry,
>
> I've been looking over PolyClusters for little while and think it's
> great, but I'm having trouble following your examples. They're over
> my head. I'd like to do something like what you're talking about, but
> with polygons instead of lines: say, three or four arrays of polygons
> with different colors. Do you have any documentation other than your
> examples page?

Sorry - no documentation yet. The API is still changing. The Hawaii
example is fairly simple. You can change color in bulk with the
setColor method.

var polyarray=["poly0","poly1","poly2","poly3", ... ];
var
color={stroke:,fill:,strokeColor:,fillColor:,strokeAlpha:,fillAlpha:,weight:};
cluster.setColor(polyarray,color);

[PhilR8]

I guess I'll wait for the API to mature for the documentation.
Thanks.

[bratliff]

On Feb 26, 6:48 pm, PhilR8 <phi...@gmail.com> wrote:
> I guess I'll wait for the API to mature for the documentation.
> Thanks.

I will try to document the important stuff. I am planning to change
the methods to conform to Google's terminology.

"setColor" will be "setStyle"
"fillAlpha" will be "fillOpacity"
"strokeAlpha" will be "strokeOpacity"

I have tried unsuccessfully to have Google make the "idle" event
automatic. I cannot imagine anyone doing anything useful with an
OverlayView without an "idle" event. The request was rejected. It
looks like I will have to make changes to accommodate it. If the guys
at Google actually had to design applications, the API might look a
lot different.

[Chad Killingsworth]

On Feb 27, 8:04 am, bratliff <bratl...@umich.edu> wrote:
> I have tried unsuccessfully to have Google make the "idle" event
> automatic.  I cannot imagine anyone doing anything useful with an
> OverlayView without an "idle" event.

Just this week I wrote a simple marker overlay that doesn't use/need
idle.

Chad Killingsworth

[bratliff]

On Feb 27, 2:27 pm, Chad Killingsworth

How do you deal with transitions to / from - in view / out of view ?

[Chad Killingsworth]

In my case, I'm not. The dom nodes are not removed if they are out of
view. Based on my map's use cases, at any given zoom level it is
highly probable that the majority of these dom nodes will be on
screen.

I'm not trying to create an in-general solution for distribution. I
simply needed to handle my specific map needs. In this case idle
wasn't needed and would have added extra overhead. My map is designed
for use on iPhones and Androids where processing power is limited.

Chad Killingsworth

[bratliff]

On Feb 27, 2:53 pm, Chad Killingsworth

<chadkillingswo...@missouristate.edu> wrote:
> In my case, I'm not. The dom nodes are not removed if they are out of
> view. Based on my map's use cases, at any given zoom level it is
> highly probable that the majority of these dom nodes will be on
> screen.
>
> I'm not trying to create an in-general solution for distribution. I
> simply needed to handle my specific map needs. In this case idle
> wasn't needed and would have added extra overhead. My map is designed
> for use on iPhones and Androids where processing power is limited.
>
> Chad Killingsworth

What I am suggesting is to the call the "chadsClass.idle()" method if
it is defined. Otherwise, do nothing. The overhead is practically
zero. It is one "if" statement in the API. In your case it will fail
but in many cases it will succeed. It will eliminate explicit event
listeners which waste resources, consume memory & cause leaks.

If the API provided:

OverlayView.prototype.idle=function(){};

the subclass could override it. The "fall back" superclass would
simple return. The "if" statment is no longer required. The "idle"
method always exists even if it does nothing.

For me, "onAdd()" does nothing useful. I do not define it.
Everything works fine. The application does not crash.