Resetting the zIndex of a Polygon

[Jeff Schnitzer]

How can I get set the zIndex of a Polygon?

I display a few hundred polygons on a map. When the map moves around,
I fetch some new polygons and render them.

I can initialize the original zIndexes in the order that I place the
polygons, yes. But then I get some new polygons and need to
interleave them with the old ones. I don't want to delete and redraw
every single polygon just to set the zIndexes.

Is there a way to get the raw element that represents a polygon?

Thanks,
Jeff

[Marcelo]

On Feb 25, 4:53 am, Jeff Schnitzer <j...@infohazard.org> wrote:
> I don't want to delete and redraw
> every single polygon just to set the zIndexes.

If you don't want, then you don't want. :-)
Polygons are not DOM objects, so they don't have a z-Index. The
elements that represent them are different in different browsers, (ie,
SVG, VML). The API implements cross-browser code to make it easier for
you to add these elements on any browser.
In any case, you don't need to "redraw". Just put them in the order
you want by
setMap(null);
setMap(map);

>
> Is there a way to get the raw element that represents a polygon?

Yes, climbing the DOM tree, but it is unreliable, as the DOM structure
may change without notice.

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

>
> Thanks,
> Jeff

[bratliff]

Are you using the API to display a few hundred polys ?

Do you have an example you could post ?

The zIndex is not an issue unless the polys overlap. CANVAS uses a
different color blending algorithm than SVG. It can be controlled
with the "globalCompositeOperation" but to my knowledge, the API does
not provide a way to access it.

Each CANVAS / SVG / VML element resides in a parent DIV. For CANVAS,
polys in the same tile reside in the same CANVAS element. Changing
the zIndex of the parent DIV will reprioritize the polys but the
results may differ between browsers.

[Jeff Schnitzer]

Thanks to both of you. It makes perfect sense now. I'll just
setMap(null) and back for the entire set.

There's a fair bit of overlap in my polygons. I've implemented
rollovers, so I need to ensure that my polygons are always ordered
with the smaller ones on top, even though the polygons change with map
center and zoom. Thus the z-order issue.

At the moment I'm rendering exactly 100 polygons of various shapes and
sizes, but that number could go up (or down) depending on performance
(network as well as rendering).

The app is Mobcast (http://www.mobca.st/map), but the polygon-related
stuff is not public yet. If you're curious, email me and I'll send
you a private link. It's built on Maps v3 with a GWT wrapper.

Thanks,
Jeff

[Ben Appleton]

We think zIndex control for polylines/polygons would be useful, so we're adding support for that to the API.

On 26 Feb 2010 13:05, "Jeff Schnitzer" <je...@infohazard.org> wrote:

Thanks to both of you.  It makes perfect sense now.  I'll just
setMap(null) and back for the entire set.

There's a fair bit of overlap in my polygons.  I've implemented
rollovers, so I need to ensure that my polygons are always ordered
with the smaller ones on top, even though the polygons change with map
center and zoom.  Thus the z-order issue.

At the moment I'm rendering exactly 100 polygons of various shapes and
sizes, but that number could go up (or down) depending on performance
(network as well as rendering).

The app is Mobcast (http://www.mobca.st/map), but the polygon-related
stuff is not public yet.  If you're curious, email me and I'll send
you a private link.  It's built on Maps v3 with a GWT wrapper.

Thanks,
Jeff

On Feb 25, 5:46 am, bratliff <bratl...@umich.edu> wrote:

> On Feb 25, 3:53 am, Jeff Schnitzer <j......

[bratliff]

On Feb 26, 3:22 am, Ben Appleton <apple...@google.com> wrote:
> We think zIndex control for polylines/polygons would be useful, so we're
> adding support for that to the API.

In order to do it for CANVAS, you will have to move each poly into its
own CANVAS element. Individual 256 pixel by 256 pixel CANVAS elements
are 64K dwords = 256K bytes. In the case of SVG, you may have to move
each "path" element to its own "svg" container in order to apply a
zIndex. It seems like a lot of extra overhead for marginal benefit.
It will impede dragging, panning and zooming.

[bratliff]

On Feb 26, 12:28 am, Jeff Schnitzer <j...@infohazard.org> wrote:
> Thanks to both of you. It makes perfect sense now. I'll just
> setMap(null) and back for the entire set.
>
> There's a fair bit of overlap in my polygons. I've implemented
> rollovers, so I need to ensure that my polygons are always ordered
> with the smaller ones on top, even though the polygons change with map
> center and zoom. Thus the z-order issue.
>
> At the moment I'm rendering exactly 100 polygons of various shapes and
> sizes, but that number could go up (or down) depending on performance
> (network as well as rendering).
>
> The app is Mobcast (http://www.mobca.st/map), but the polygon-related
> stuff is not public yet. If you're curious, email me and I'll send
> you a private link. It's built on Maps v3 with a GWT wrapper.
>
> Thanks,
> Jeff

Are you able to display 100 polys simultaneously with the API ?

If not, I have a "light weight" poly facility with several demos at:

http://www.polyarc.us/polycluster

[Marcelo]

On Feb 26, 12:04 pm, bratliff <bratl...@umich.edu> wrote:
>
> Are you able to display 100 polys simultaneously with the API ?
>

I am able to display more than 1000, but they are tiny, (5 to 10
points each). :-)

[bratliff]

On Feb 26, 12:27 pm, Marcelo <marcelo...@hotmail.com> wrote:

> I am able to display more than 1000, but they are tiny, (5 to 10
> points each). :-)

I duplicated your experiment.

API:

http://www.polyarc.us/polycluster/api

PolyCluster:

http://www.polyarc.us/polycluster/cluster

If you click "Examine" you will see the different DOM structures. If
you drag or pan or zoom, you will see the improvement in performance.

It appears a "path" element can have a "style.zIndex" property without
a separate "svg" element. Regardless, if a lot of polys are involved,
CANVAS blows the doors off SVG.

[Marcelo]

On Feb 26, 6:40 pm, bratliff <bratl...@umich.edu> wrote:
> I duplicated your experiment.
>
> API:
>
>    http://www.polyarc.us/polycluster/api
>
> PolyCluster:
>
>    http://www.polyarc.us/polycluster/cluster
>

Berry,

That quite amazing, even in IE! :-)
But as someone mentioned in another thread, while I think your code is
very elegant and highly efficient, I am unable to read it.

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

> If you click "Examine" you will see the different DOM structures.  If

[bratliff]

On Feb 27, 6:22 am, Marcelo <marcelo...@hotmail.com> wrote:
> Berry,
>
> That quite amazing, even in IE! :-)
> But as someone mentioned in another thread, while I think your code is
> very elegant and highly efficient, I am unable to read it.
>
> --
> Marcelo -http://maps.forum.nu
> --

Thanks Marcelo,

I had to do a lot of code consolidation to prevent IE from displaying
"Script running slowly ... " messages. IE counts the number of
statements executed rather than measuring elapsed time to reduce the
dependency on CPU chip speed.

http://support.microsoft.com/kb/175500

One very ugly loop with one 750 character statement is simply to
eliminate another "set-up" loop. It is deeply embedded in other loops
which means it receives heavy traffic. Also, some browsers perform
"just in time" compilation of the JavaScript. Individual complex
statements are well suited for optimization. Compilers can remove
redundant sub-expressions but have difficulty analyzing flow. The
overhead may not be worth the effort.

Another reason is to prevent the "cut & paste" crowd from stealing my
code. I am happy to have people use it but not butcher it.

Some of the optimization techniques are proprietary. I am exploring
my licensing options.

Berry

For what it is worth, 1000 polys of four vertices each are not a good
demonstration of the optimization capabilities. Point reduction
cannot be performed on just four vertices. The intermediate cache is
worthless. It requires big polys to do serious optimization.