I have added "click" / "cover" capabilities. Instead of individual
event listeners for every poly, you add a single event listener for
the entire PolyCluster.
For "mousedown" / "mouseup", use:
cluster.setClick(YourClickFunction);
It will be called with two arguments:
function YourClick
On Oct 8, 11:12 pm, Ben Appleton wrote:
> SVG seems to be *much* slower than Canvas though - watch out.
> On 9 Oct 2010 00:45, "bratliff" wrote:
Thanks Ben,
Have you tried CANVAS with a transparent image overlay with a "usemap"
map ?
--
You received this message because you are subscribed to
SVG seems to be *much* slower than Canvas though - watch out.
On 9 Oct 2010 00:45, "bratliff" wrote:
> On Oct 8, 2:51 am, spoco2 wrote:
>> The only problem that I have now found with using polycluster is that
>> it seems to give no mouseevent ability to the created polygons, so I
>> can't have mo
On Oct 8, 2:51 am, spoco2 wrote:
> The only problem that I have now found with using polycluster is that
> it seems to give no mouseevent ability to the created polygons, so I
> can't have mouseover/mouseout/click events.
>
> Which is a little limiting.
>
> However the performance of it on a mobil
The only problem that I have now found with using polycluster is that
it seems to give no mouseevent ability to the created polygons, so I
can't have mouseover/mouseout/click events.
Which is a little limiting.
However the performance of it on a mobile device is leaps and bounds
above the google
And yes, it works an absolute treat. We can now keep using our server
calls which return encoded polylines, and yet get the speed increases
of the new API. Thanks for that. :)
On Oct 7, 4:38 pm, spoco2 wrote:
> That is pretty interesting actually, yeah, might actually work in the
> short term for
That is pretty interesting actually, yeah, might actually work in the
short term for us to be able to still source our encoded polys.
On Oct 7, 3:44 am, bratliff wrote:
> On Oct 4, 6:00 am,spoco2 wrote:
>
>
>
> > Hi all,
>
> > I am at a loss as to how to neatly define a complex path polygon/
> >
On Oct 4, 6:00 am, spoco2 wrote:
> Hi all,
>
> I am at a loss as to how to neatly define a complex path polygon/
> polyline (think a postcode boundary) in V3 of the API compared to V2.
>
> We have an app that currently uses the V2 API to draw about 50 complex
> polygons at a time on a map. This we
Other than the official documentation, here's a good start:
http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/
Chad Killingsworth
On Oct 5, 4:30 am, sgiddings wrote:
> "The "old" encoding algorithms are freely available if you wanted to
> extend the APIs classes. "
>
> Can you tell me
"The "old" encoding algorithms are freely available if you wanted to
extend the APIs classes. "
Can you tell me how to get hold of these ?
On Oct 5, 1:10 am, Rossko wrote:
> > Also, it's just plain messy to have a loop that steps over all the
> > points creating a new instance of a LatLng for ea
> Also, it's just plain messy to have a loop that steps over all the
> points creating a new instance of a LatLng for each point, surely that
> sort of drudgery should be hidden via a Google API call like
> Polyline.setPathByPoints(pointarray); or similar, and all the looping
> etc. can be done beh
Hi Chad,
I have read all those discussions, and I never particularly used
encoded polylines for their speed benefits on the client, moreso for
their transmission benefits, they take a lot less to transmit.
Also, it's just plain messy to have a loop that steps over all the
points creating a new in
There are several discussions regarding this topic in the group. Here
a just a couple:
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/c03a8115e2baf980/39cc9ebf23cbc500
http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/8b994d53c9decc14/fef6f1c7e61c
13 matches
Mail list logo
