click / mousemove / mouseover / mouseout event handlers

[bratliff]

I have built a set of stopgap event handlers (click, mousemove,
mouseover, mouseout) for V3:

www.polyarc.us/polycluster/event.html

which I expect Google will replace at some point. In the mean time,
you will be able to provide mouse position feedback. I have replaced
the "click" event handler because changes made to V2 for the iPhone
(v2.122) are incompatable with my PC.

A previous version did not work properly for Firefox. I believe I
have fixed the bug.

[Esa]

I appreciate your work, Bratliff but don't you understand that they
are doing dragging by CSS3 'transform'. That is a position movement
that you cannot read by DOM.

I tried 'click' with Polyline and I was disappointed. 'mousedown' and
'mouseup' return equal coordinates undependent of drag.
We need the Point() of actual position.

Polygon 'click' must be cured immediately. In a day or two there will
be a crowd of people who have a fullscreen polygon that is stealing
all the clicks.

Polygon 'click' is not documented but it is mentioned in of the
examples. The object that Polygon 'click' returns, does not include
pixel property at all, and I can imagine the reason.

I can see that you are using tile based SVG (with some overlap). You
never asked any opinions.

[Esa]

Polygon and Polyline have undocumented methods:

set_map();
get_map();
map_changed();

I have not tried what they do, but they exist.

[bratliff]

On Sep 24, 12:08 am, Esa <esa.ilm...@gmail.com> wrote:
> I appreciate your work, Bratliff but don't you understand that they
> are doing dragging by CSS3 'transform'. That is a position movement
> that you cannot read by DOM.

I don't know what a CSS3 "transform" is. I am not attempting to
replace "drag" which requires mouse capture / mouse release. I am
just offering a quick & dirty little hack to fill a void. It works
across browsers. I have tested FF & IE. It works for both.

> I tried 'click' with Polyline and I was disappointed. 'mousedown' and
> 'mouseup' return equal coordinates undependent of drag.
> We need the Point() of actual position.
>
> Polygon 'click' must be cured immediately. In a day or two there will
> be a crowd of people who have a fullscreen polygon that is stealing
> all the clicks.
>
> Polygon 'click' is not documented but it is mentioned in of the
> examples. The object that Polygon 'click' returns, does not include
> pixel property at all, and I can imagine the reason.
>
> I can see that you are using tile based SVG (with some overlap). You
> never asked any opinions.

I am not using SVG. I use CANVAS for polys in another project. For
"mousemove" / "mouseover" / "mouseout", I am using built-in event
handlers, neither SVG nor CANVAS. It is just a stupid little hack to
fill a void.

"Opinions" on what ? I am listening. Please fire away. I have asked
for feedback on a different project, "Light Weight Polys".

[Esa]

> I can see that you are using tile based SVG (with some overlap). You
> never asked any opinions.

I did not mean you Bratliff, you are the only one trying to make
discussion. Now, the decicision is made for ten years. It is tile
based SVG.

I predict hat the tile size will soon bee 512x512.

[Ben Appleton]

On Thu, Sep 24, 2009 at 10:08 AM, Esa <esa.i...@gmail.com> wrote:

I appreciate your work, Bratliff but don't you understand that they
are doing dragging by CSS3 'transform'. That is a position movement
that you cannot read by DOM.

I tried 'click' with Polyline and I was disappointed. 'mousedown' and
'mouseup' return equal coordinates undependent of drag.
We need the Point() of actual position.

Thanks for the prompt report, we'll look into this.

  

Polygon 'click' must be cured immediately. In a day or two there will
be a crowd of people who have a fullscreen polygon that is stealing
all the clicks.

 

polys do not steal 'click' from the map; 'click' fires on both.  Or, can you tell in which browser the poly steals 'click'?

Polygon 'click' is not documented but it is mentioned in of the
examples. The object that Polygon 'click' returns, does not include
pixel property at all, and I can imagine the reason.

I can see that you are using tile based SVG (with some overlap). You
never asked any opinions.

Underneath we use VML/SVG/Canvas depending on the browser.  This is an implementation detail which is not exposed in the API, so we can change it as we discover better solutions.

 

[Ben Appleton]

On Thu, Sep 24, 2009 at 10:25 AM, Esa <esa.i...@gmail.com> wrote:

Polygon and Polyline have undocumented methods:

  set_map();
  get_map();
  map_changed();

.set_map() is deprecated in favor of .setMap(), which is documented:

http://code.google.com/apis/maps/documentation/v3/reference.html#Polyline

 

.map_changed is part of the implementation; we call it internally.

[bratliff]

I am confused. Are you talking about my "mousemove" / "mouseover" /
"mouseout" event handlers or Google's polys ? I have a "Light Weight
Poly" facility. It is discussed in another thread.

[Esa]

On Sep 24, 3:44 am, bratliff <bratl...@umich.edu> wrote:


> I don't know what a CSS3 "transform" is.  

It is the way how dragging is made in v3. A nice technique but DOM
does not know anything about it. That is the reason why it so
difficult to provide us pixel coordinates.

> I am not using SVG.  I use CANVAS for polys in another project.  For

Just announced Polyline and Polygon are tile based SVG.

>
> "Opinions" on what ?  I am listening.  Please fire away.  I have asked
> for feedback on a different project, "Light Weight Polys".

Sorry, I meant Google people. I wrote the other post before this with
some explanation. Sorry again about my bad wording. My mother tongue
is Finnish. I am am still learning.

[bratliff]

On Sep 24, 1:12 am, Esa <esa.ilm...@gmail.com> wrote:
> On Sep 24, 3:44 am, bratliff <bratl...@umich.edu> wrote:
>
> > I don't know what a CSS3 "transform" is.
>
> It is the way how dragging is made in v3. A nice technique but DOM
> does not know anything about it. That is the reason why it so
> difficult to provide us pixel coordinates.

Dragging works in all supported browsers, even in Internet Explorer.
I suspect it uses mouse capture / mouse release.

> Sorry, I meant Google people.

Yes, I am disappointed it was not discussed among the group also. I
did everything I could to discourage repeating the mistake of
"fromEncoded" "level strings". It looks like it worked. I may have
made a few enemies.

[Ben Appleton]

Not at all; we agree with your assessment of the old polyline encoding scheme.  We will need *some* form of polyline encoding for directions, and we may even use the old polyline encoding scheme, but we've taken care to perform LoD simplification in the client wherever possible so that by default polylines are fast without having to be encoded also.

 

[Esa]

On Sep 24, 4:45 am, bratliff <bratl...@umich.edu> wrote:

> Dragging works in all supported browsers, even in Internet Explorer.

Yes it does but it is extremely difficult to get mouse coordinates.

> I may have
> made a few enemies.

No you have not.

I made a quick test page to demonstrate the events.
http://koti.mbnet.fi/ojalesa/v3/v3events.htm

I guess it works only with FF because it is using toSource() method.

You can see that mousedown and mouseup return equal coordinates even
if you drag between them.

[Esa]

This is for Bratliff. It is my simple test page that displays number
of SVG blocks and number of "L" segments in "path" elements.

http://koti.mbnet.fi/ojalesa/v3/polygon_1.htm

Click on map displays the results. Zooming in and out reveals that
someone is controlling the number of vertices shown. Maybe Douglas or
Peucker.

[bratliff]

On Sep 24, 1:52 am, Ben Appleton <apple...@google.com> wrote:
> Not at all; we agree with your assessment of the old polyline encoding
> scheme. We will need *some* form of polyline encoding for directions, and
> we may even use the old polyline encoding scheme, but we've taken care to
> perform LoD simplification in the client wherever possible so that by
> default polylines are fast without having to be encoded also.

"LoD" ?

You are welcome to use any or all of my compression algorithm:

www.polyarc.us/polypack.js

It is bit based rather than byte based for a small gain in space. It
is pixel based (fixed point) rather than Lat/Lon coordinate based
(floating point) for a large gain in space. It is lossless within the
limitations of a 32 bit unsigned integer which is equivalent to zoom
level 24 with 256x256 pixels per tile.

The arbitrary ASCII alphabet avoids the use of the backslash
character. The actual alphabet can be negotiated between sender &
receiver for very weak encryption.

[bratliff]

On Sep 24, 2:11 am, Esa <esa.ilm...@gmail.com> wrote:
> Click on map displays the results. Zooming in and out reveals that
> someone is controlling the number of vertices shown. Maybe Douglas or
> Peucker.

The Douglas-Peucker algorithym is too slow for "on-the-fly"
compression. It is a recursive algorithm very similar to "Quick
Sort". Despite many opinions to the contrary, I believe D-P is
suitable for polylines but not for polygons. A simple merging of
identical points works well enough. At different zoom levels, the
spread between adjacent points changes. Eventually, two adjacent
points occupy the same pixel. You could do a proximity test but I
doubt the extra math is worth it. Also, I believe CANVAS/SVG/VML may
do some internal point reduction.

[Ben Appleton]

We're not using DP, it is too slow as you point out.

On Sep 25, 2009 12:46 AM, "bratliff" <brat...@umich.edu> wrote:

On Sep 24, 2:11 am, Esa <esa.ilm...@gmail.com> wrote: > Click on map displays the results. Zooming ...

The Douglas-Peucker algorithym is too slow for "on-the-fly"
compression.  It is a recursive algorithm very similar to "Quick
Sort".  Despite many opinions to the contrary, I believe D-P is
suitable for polylines but not for polygons.  A simple merging of
identical points works well enough.  At different zoom levels, the
spread between adjacent points changes.  Eventually, two adjacent
points occupy the same pixel.  You could do a proximity test but I
doubt the extra math is worth it.  Also, I believe CANVAS/SVG/VML may
do some internal point reduction.

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are sub...

[Ben Appleton]

Sorry, by LoD I mean Level of Detail, such as that computed by DP.  We do not yet perform any compression in the browser, only LoD assignment, indexing and later vector extraction + clipping + rendering.

On Sep 25, 2009 12:05 AM, "bratliff" <brat...@umich.edu> wrote:

On Sep 24, 1:52 am, Ben Appleton <apple...@google.com> wrote: > Not at all; we agree with your asse...

"LoD" ?

You are welcome to use any or all of my compression algorithm:

   www.polyarc.us/polypack.js

It is bit based rather than byte based for a small gain in space.  It
is pixel based (fixed point) rather than Lat/Lon coordinate based
(floating point) for a large gain in space.  It is lossless within the
limitations of a 32 bit unsigned integer which is equivalent to zoom
level 24 with 256x256 pixels per tile.

The arbitrary ASCII alphabet avoids the use of the backslash
character.  The actual alphabet can be negotiated between sender &
receiver for very weak encryption.

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are su...

[bratliff]

On Sep 24, 8:43 pm, Ben Appleton <apple...@google.com> wrote:
> Sorry, by LoD I mean Level of Detail, such as that computed by DP. We do
> not yet perform any compression in the browser, only LoD assignment,
> indexing and later vector extraction + clipping + rendering.

For CANVAS, clipping is not required. Anything beyond the tile
boundaries is not rendered. It avoids having to interpolate
transitional segments (from outside to inside or from inside to
outside).

For riciculously large polys, I found it useful to do a quick
aggregation by tile. I call it a "skip list". For consecutive
verticies in the same tile, I keep their beginning & ending offsets.
To build an actual tile, the "skip list" can be used to bypass a large
number of verticies in one comparison. Dragging & panning do not
require the "skip list" do be rebuilt. Returning to a previously
visited zoom level will reuse an existing "skip list". I have
experimented with combining zoom levels in the same "skip list". It
means building fewer "skip lists" but at intermediate zoom levels the
"skip list" is not optimal.

I have an experimental test bed in which "tile size" & "skip list" can
be changed. It is helpful for determining the point at which the
browser collapses.

www.polyarc.us/polycluster/variable.html

"Tile Size" is obvious. "Cache Level" determines the number of zoom
levels serviced by the same "skip list". The default is 4. It
results in the following:

0 0, 1, 2, 3
1 4, 5, 6, 7
2 8, 9,10,11
3 12,13,14,15
4 16,17,18,19
5 20,21,22,23

The "Examine" button will display the actual DOM elements.

[Ben Appleton]

On Fri, Sep 25, 2009 at 7:44 AM, bratliff <brat...@umich.edu> wrote:

On Sep 24, 8:43 pm, Ben Appleton <apple...@google.com> wrote:
> Sorry, by LoD I mean Level of Detail, such as that computed by DP.  We do
> not yet perform any compression in the browser, only LoD assignment,
> indexing and later vector extraction + clipping + rendering.

For CANVAS, clipping is not required.  Anything beyond the tile
boundaries is not rendered.  It avoids having to interpolate
transitional segments (from outside to inside or from inside to
outside).

Thanks; as it turns out I'm optimizing the implementation this week, and I found that skipping clipping saves 10% of rendering time in most browsers (Safari and Chrome have very good JS engines so it's not a big win there).

 

For riciculously large polys, I found it useful to do a quick
aggregation by tile.  I call it a "skip list".  For consecutive
verticies in the same tile, I keep their beginning & ending offsets.
To build an actual tile, the "skip list" can be used to bypass a large
number of verticies in one comparison.  Dragging & panning do not
require the "skip list" do be rebuilt.  Returning to a previously
visited zoom level will reuse an existing "skip list".  I have
experimented with combining zoom levels in the same "skip list".  It
means building fewer "skip lists" but at intermediate zoom levels the
"skip list" is not optimal.

Yup.  When rendering a tile at a low zoom level, do you also remove unnecessary vertices?  I found this increased panning/zooming speed by at least 2x on my tests.  Exactly how much it improves depends on the geometry of the particular poly.

[bratliff]

On Sep 24, 10:37 pm, Ben Appleton <apple...@google.com> wrote:

The only point reduction I do is to discard points collapsing into the
same pixel. I figure CANVAS which is complied can eliminate
extraneous points much quicker than JavaScript which is interpreted.

I suppose you could quickly test the height of the triangle of each
set of three consecutive points without too much overhead. But what
if:

A-B-C says "discard B"
B-C-D says "discard C"
C-D-E says "discard D"
D-E-F says "discard E"

The result is A-F which might be an ugly looking line segment.
Additional analysis will overhead.

I do summarize all "off-tile" points to the central point (128,128) in
the tile which causes many to be duplicates. I also relocate all
exterior tiles toward the target tile either vertically or
horizontally or both to be just one tile away.

The result is every "off-tile" vertex has only one of eight pixel
positions:

-128, -128
+128, -128
+384, -128
-128,+128
+384,+128
-128,+384
+128,+384
+384,+384

The exception is the "off-tile" vertex of a transitional pair which I
preserve in order to avoid interpolation. Occasionally, both the left
& right vertex of a segment are on opposite sides of the target tile.
The line segment might cross the target tile without the target tile
actually containing either vertex. For all practical purposes, an
"off-tile" vertex is limited to just eight choices. The result is
massive point reduction of identical pixels.

I am optimizing for the 10,000 point poly perhaps at the expense of
the 1,000 point poly. The "skip list" really helps if a very small
percentage of the poly is visible.

[Ben Appleton]

I've found that calling Canvas .moveTo()/.lineTo() takes a non-trivial amount of time, so that removing unused vertices (which can be done once before rendering) speeds up rendering.

 

I suppose you could quickly test the height of the triangle of each
set of three consecutive points without too much overhead.  But what
if:

   A-B-C says "discard B"
   B-C-D says "discard C"
   C-D-E says "discard D"
   D-E-F says "discard E"

The result is A-F which might be an ugly looking line segment.
Additional analysis will overhead.

Our current implementation is more like

A-B-C says "discard B"

A-C-D says "discard C"

A-D-E says "don't discard D"; push vertex A

D-E-F says ...

[bratliff]

On Sep 25, 3:14 am, Ben Appleton <apple...@google.com> wrote:
> > The only point reduction I do is to discard points collapsing into the
> > same pixel. I figure CANVAS which is complied can eliminate
> > extraneous points much quicker than JavaScript which is interpreted.
>
> I've found that calling Canvas .moveTo()/.lineTo() takes a non-trivial
> amount of time, so that removing unused vertices (which can be done once
> before rendering) speeds up rendering.

Thanks. Good to know. I will experiment with it. Right now, I am
playing with an idea of generating one 1024x1024 tile which I will
clone into sixteen 256x256 tiles.

> > I suppose you could quickly test the height of the triangle of each
> > set of three consecutive points without too much overhead. But what
> > if:
>
> > A-B-C says "discard B"
> > B-C-D says "discard C"
> > C-D-E says "discard D"
> > D-E-F says "discard E"
>
> > The result is A-F which might be an ugly looking line segment.
> > Additional analysis will overhead.
>
> Our current implementation is more like
> A-B-C says "discard B"
> A-C-D says "discard C"
> A-D-E says "don't discard D"; push vertex A
> D-E-F says ...

OK, but be aware it is not symmetrical in opposite directions which
means two polys with a common boundary will compress differently. You
may see gaps and/or overlaps along their common boundary.

[Ben Appleton]

On Fri, Sep 25, 2009 at 1:54 PM, bratliff <brat...@umich.edu> wrote:

On Sep 25, 3:14 am, Ben Appleton <apple...@google.com> wrote:
> > The only point reduction I do is to discard points collapsing into the
> > same pixel.  I figure CANVAS which is complied can eliminate
> > extraneous points much quicker than JavaScript which is interpreted.
>
> I've found that calling Canvas .moveTo()/.lineTo() takes a non-trivial
> amount of time, so that removing unused vertices (which can be done once
> before rendering) speeds up rendering.

Thanks.  Good to know.  I will experiment with it.  Right now, I am
playing with an idea of generating one 1024x1024 tile which I will
clone into sixteen 256x256 tiles.

Interesting; I've been following your thread with Paul, you guys are way ahead on the Canvas side.

 

> > I suppose you could quickly test the height of the triangle of each
> > set of three consecutive points without too much overhead.  But what
> > if:
>
> >    A-B-C says "discard B"
> >    B-C-D says "discard C"
> >    C-D-E says "discard D"
> >    D-E-F says "discard E"
>
> > The result is A-F which might be an ugly looking line segment.
> > Additional analysis will overhead.
>
> Our current implementation is more like
> A-B-C says "discard B"
> A-C-D says "discard C"
> A-D-E says "don't discard D"; push vertex A
> D-E-F says ...

OK, but be aware it is not symmetrical in opposite directions which
means two polys with a common boundary will compress differently.  You
may see gaps and/or overlaps along their common boundary.

Yup, I appreciate this is neither symmetric nor optimal (in terms of minimizing the number of vertices).  However we only simplify two edges if the resulting edge is within half of the strokeWeight at the target zoom level.  For example if the strokeWeight is 1 pixel we simplify with a tolerance of 1/2 a pixel, and the resulting poly is indistinguishable from the original (once its coordinates are rounded to the nearest pixel again).  So it should not be possible to create a gap or excessive overlaps.

Or rather if you do see that, please file a bug :)

 

[bratliff]

On Sep 25, 4:04 am, Ben Appleton <apple...@google.com> wrote:

> > OK, but be aware it is not symmetrical in opposite directions which
> > means two polys with a common boundary will compress differently. You
> > may see gaps and/or overlaps along their common boundary.
>
> Yup, I appreciate this is neither symmetric nor optimal (in terms of
> minimizing the number of vertices). However we only simplify two edges if
> the resulting edge is within half of the strokeWeight at the target zoom
> level. For example if the strokeWeight is 1 pixel we simplify with a
> tolerance of 1/2 a pixel, and the resulting poly is indistinguishable from
> the original (once its coordinates are rounded to the nearest pixel
> again). So it should not be possible to create a gap or excessive overlaps.
>
> Or rather if you do see that, please file a bug :)

I tried something similar once. I discovered I could eliminate
approximately 1% of the pixels if I had fairly clean polys to start
with (U.S. Census Department Cartographic Boundary Files). Of course,
if I was working with a bunch of trash, compression did help. You
will be receiving polys from your Direction Finder Service which ought
to be very well oiled. How much reduction are you able to achieve
with realistic polys ?

FWIW, some polys are filled but not stroked. The constant line width
is the only thing preventing scaling between zoom levels.

[Ben Appleton]

10-100x for cross-country driving directions polylines.  For a fractal test poly, I've seen 10000x compression, but my browser wasn't very happy :)

 

FWIW, some polys are filled but not stroked.

For those I default to 1/2-pixel tolerance.

 

 The constant line width
is the only thing preventing scaling between zoom levels.

You could scale the fill and overlay the stroke, but that probably does not save much time.

 

[bratliff]

On Sep 25, 4:57 am, Ben Appleton <apple...@google.com> wrote:

> 10-100x for cross-country driving directions polylines. For a fractal test
> poly, I've seen 10000x compression, but my browser wasn't very happy :)
>
> > FWIW, some polys are filled but not stroked.
>
> For those I default to 1/2-pixel tolerance.
>
> > The constant line width
> > is the only thing preventing scaling between zoom levels.
>
> You could scale the fill and overlay the stroke, but that probably does not
> save much time.

Actually I believe it would be worse because the path still has to be
built. Both stroke & fill are fast. In fact, if a tile contains just
one poly, you can change colors almost immediately without rebuilding
the path. Just set globalCompositeOperation='copy', reissue the
stroke & reissue the fill with different color & with different alpha.

I have been thinking about common boundaries between polys. It is
more important to have the polys butt up tightly against each other
than it is to draw the common boundary exactly along the center line
of the river separating the two adjacent states (polys).

What if you did the same three point comparisons without actually
discarding points. Instead, you keep track of the first & last point
in a series of discardable points. With the first & last point, you
recheck the intermediate points with a new base for the triangle.
Each point can be accepted or rejected based on its deviation from the
straight line connecting the first & last point. It is symmetric. It
will accept or reject the same points in either direction. Both polys
will be identical along their common boundary.

A-B-C says discard B
B-C-D says discard C
C-D-E says discard D
D-E-F says discard E

Rescan using:

A-B-F
A-C-F
A-D-F
A-E-F

Discard some combination of B C D E based strictly on its deviation
from A-F.

[Ben A]

On Sep 24, 11:58 am, Esa <esa.ilm...@gmail.com> wrote:
> On Sep 24, 4:45 am, bratliff <bratl...@umich.edu> wrote:
>
> > Dragging works in all supported browsers, even in Internet Explorer.
>
> Yes it does but it is extremely difficult to get mouse coordinates.
>
> > I may have
> > made a few enemies.
>
> No you have not.
>

> I made a quick test page to demonstrate the events.http://koti.mbnet.fi/ojalesa/v3/v3events.htm

>
> I guess it works only with FF because it is using toSource() method.
>
> You can see that mousedown and mouseup return equal coordinates even
> if you drag between them.

Esa, I don't see a bug. If you mousedown, drag, mouseup, the map
moves too. So if I understand you correctly, you would expect that
the mousedown and mouseup return equal coordinates when you drag
between them, precisely because the map dragged too.

[Esa]

On Sep 28, 6:54 am, Ben A <ben.apple...@gmail.com> wrote:

> Esa, I don't see a bug.  If you mousedown, drag, mouseup, the map
> moves too.  So if I understand you correctly, you would expect that
> the mousedown and mouseup return equal coordinates when you drag
> between them, precisely because the map dragged too.

Right. Sorry about the confusion. I was thinking to disable click
event of polygon if map is dragged between mousedown and mouseup. Like
map click event works.

If you zoom very close inside a polygon, you cannot avoid polygon
click events when you just try to move the map.

I had a plan to read the pixel coordinates of the polygon mousedown
and mouseup. The event object of those however do not contain pixel
coordinates.

I tried to use latLng coordinates instead but of course that did not
do the job. You just explained why.

Actually the issue is the missing pixel property of the mousedown,
mouseup and click events.

[Esa]

On Sep 29, 11:41 pm, Esa <esa.ilm...@gmail.com> wrote:

> Actually the issue is the missing pixel property of the mousedown,
> mouseup and click events.

Looking at the documentation today I realized that there is no pixel
property anymore in the mouse event object.

[bratliff]

"Pixel" could be interpreted several different ways:

Absolute (Relative to 0,0)
Relative to the container DIV
Relative to the slippery DIV with the tiles & polys

Pamela / Ben,

What about "mousemove", "mouseover", "mouseout" event handlers for the
map canvas ? If "no", I will have to do it myself. If "yes", I will
wait. Admittedly, such events are meaningless to iPhone users.

What about a way to disable iPhone "touch" / "mouse" emulation for
other browsers ? I am convinced it is the cause of the misdirected
clicks I am experiencing in:

www.polyarc.us/polycluster/examine.html

But it is difficult to prove without source code. I will try to block
your click event handler to see if it behaves correctly.

[Ben Appleton]

Mousemove/over/out for the map canvas could just be attached to the container.  So, what would you want these events to do that you cannot already do?

On Oct 5, 2009 3:01 AM, "bratliff" <brat...@umich.edu> wrote:

On Sep 30, 6:43 pm, Esa <esa.ilm...@gmail.com> wrote: > On Sep 29, 11:41 pm, Esa <esa.ilm...@gmail....

"Pixel" could be interpreted several different ways:

   Absolute (Relative to 0,0)
   Relative to the container DIV
   Relative to the slippery DIV with the tiles & polys

Pamela / Ben,

What about "mousemove", "mouseover", "mouseout" event handlers for the
map canvas ?  If "no", I will have to do it myself.  If "yes", I will
wait.  Admittedly, such events are meaningless to iPhone users.

What about a way to disable iPhone "touch" / "mouse" emulation for
other browsers ?  I am convinced it is the cause of the misdirected
clicks I am experiencing in:

   www.polyarc.us/polycluster/examine.html

But it is difficult to prove without source code.  I will try to block
your click event handler to see if it behaves correctly.

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are su...

[bratliff]

On Oct 4, 10:04 pm, Ben Appleton <apple...@google.com> wrote:
> Mousemove/over/out for the map canvas could just be attached to the
> container. So, what would you want these events to do that you cannot
> already do?

Convert from pixels to Lat/Lon coordinates. It requires an additional
OverlayView. Browser dependencies exist. Adding "onclick",
"onmousemove", etc. event handlers to the container DIV interferes
with your event handlers.

The file:

www.polyarc.us/polycluster/event.html

works but it requires a lot of code. Perhaps you can suggest another
way to do it.