How to properly render many polygons

[Erwin Quinto]

Hi,

Good day everyone, on our project we are trying to render a polygon
for each of the 80 provinces in the map. We followed the procedure on
how to create polygons based from the version 3 api documentation.
http://code.google.com/apis/maps/documentation/v3/overlays.html#Polygons

But we ran into a performance issue. Browser loads very slow when
displaying our map. http://philmap.000space.com/gmap-api/provinces-polygons/province-polys.html

Do any of you have suggestions on how to we can overcome this?

[Ben Appleton]

It looks like you're rendering about 80 polygons, each with hundreds to thousands of vertices.  This works but is slow in old browsers.  If you need faster performance I suggest simplifying your polygons beforehand using an algorithm such as http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm, removing vertices until performance is acceptable.

--

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.

[Ben Appleton]

To be fairer, this is slow in new browers and unusable in old browsers.

[Esa]

You can find a JavaScript implementation of Douglas-Peucker algorithm
on Bill Chadwicks page
http://www.bdcc.co.uk/Gmaps/Services.htm

[Ben Appleton]

v3 contains a JavaScript variant of Douglas-Peucker, without which this page would be much slower.  I was suggesting instead to run DP beforehand to simplify the borders of each province, throwing away vertices until the resulting map renders fast enough.

[Mickey Kataria]

On Dec 11, 2009 11:47 PM, "Ben Appleton" <appl...@google.com> wrote:

v3 contains a JavaScript variant of Douglas-Peucker, without which this page would be much slower.  I was suggesting instead to run DP beforehand to simplify the borders of each province, throwing away vertices until the resulting map renders fast enough.

On Fri, Dec 11, 2009 at 11:15 PM, Esa <esa.i...@gmail.com> wrote: > > You can find a JavaScript ...

[bratliff]

On Dec 11, 5:24 am, Erwin Quinto <erwin.qui...@gmail.com> wrote:
> Hi,
>
> Good day everyone, on our project we are trying to render a polygon
> for each of the 80 provinces in the map. We followed the procedure on

> how to create polygons based from the version 3 api documentation.http://code.google.com/apis/maps/documentation/v3/overlays.html#Polygons

>
> But we ran into a performance issue. Browser loads very slow when

> displaying our map.http://philmap.000space.com/gmap-api/provinces-polygons/province-poly...

>
> Do any of you have suggestions on how to we can overcome this?

I have built a demo using PolyCluster.

http://www.polyarc.us/alotofpolys

It loads slowly because the uncompressed poly definition file is 1.1
million bytes. Performance improves once it is loaded. I plan to
remove it in one week because it is consuming too much file space.
Grab a copy now if you are interested.

I have to disagree with the Google guys about Douglas-Peucker point
reduction. It was designed for polylines not for polygons. On
already clean polys, it consumes more resources than it saves. It
also introduces errors along the common boundaries between adjacent
polys. Unless it is applied on the same set of points in the same
direction, it will produce different results. If it is applied too
aggressively, it will produce gaps and/or overlaps along the common
boundaries.

Elimination of duplicate pixels produces almost identical results
without the computational complexity. It is symmetric which means the
same points drop out in either direction. It misses a few points
along the interpolation line connecting the two immediate neighbors.
The situation is rare enough to not really matter.

CANVAS & SVG are both compiled from C++. JavaScript is interpreted.
I prefer to let the graphics engine do the point reduction. It has a
distinct speed advantage over JavaScript.

[bratliff]

On Dec 12, 8:45 pm, bratliff <bratl...@umich.edu> wrote:

I fixed a significant bug today. It was causing tiles to be rebuilt
too often. If you have a copy of:

http://polyarc.us/polycluster.js

older than about an hour ago, throw it away. Grab a fresh copy. It
improves performance in several areas (dragging / panning / zooming /
color changing).

[bratliff]

I am experiencing a security error in v3.24 with FireFox 2.0:

Security Error: Content at http://maps.gstatic.com/intl/en_us/mapfiles/api-3/24/main.js
may not load data from http://www.provide.net/~bratliff/alotofpolys/.

Error: a.A is not a function
Source File: http://maps.gstatic.com/intl/en_us/mapfiles/api-3/24/main.js
Line: 33

v3.23 was OK

Try:

http://www.polyarc.us/alotofpolys

Then examine the Error Console

[Ben Appleton]

See other thread: we're clashing on obfuscated property names.