On Jan 7, 3:04 pm, sandy037 <[email protected]> wrote:
> @ bratliff and @ rossko
>
> > > But not too difficult. Any given update will only affect some tiles
> > > (at various zoom levels), so you can have a large cache of pre-made
> > > tiles and only update a handful for each update.
> > Perhaps he could augment yesterday's tiles with today's polys. I
> > suspect he will have to provide tiles for several different zoom
> > levels.
>
> If its the case, I will have to provide all tiles for different zoom
> levels. And the caching takes large amounts of space further. I am
> thinking of grouping sets of polylines with different IDs based on
> distance from a fixed point in a city (sets are based upon concentric
> circles or concentric rectangles) and load those polyline sets as
> needed (as the user starts dragging). Each set might have say some
> hundreds of polylines. So, is there any problem with the google API to
> render some hundreds of polylines at a time? Also, I plan to lay more
> polylines as the user starts dragging the map. If the user starts
> dragging fast, it means I have to load more and more polylines at a
> time.
>
> Do you think the above method might be feasible?
I believe the API will run out of gas with a few dozen polys.
PolyCluster is quite comfortable displaying several hundred simple
polys or a hundred complex polys. The important factor is the number
of points, not the number of polys.
The API uses SVG to render polys unless it has changed recently. SVG
supports mouse events natively but it does not scale well. SVG
requires a separate "path" element in the DOM for each poly.
PolyCluster uses CANVAS to render polys. CANVAS does not support
mouse events natively but it does scale extremely well. CANVAS tiles
are similar in performance to image tiles. CANVAS tiles (256 x 256)
each consume 256K BYTES or 64K DWORDS regardless of the number of
polys contained. Additional points will add delay to the time to
render the tile but will not change the number of pixels.
You can experiment with the "US Highways" demo at:
http://www.polylib.us
The actual files can be found at:
http://www.polylib.us/polycluster/road
You will be able to browse the directory. The "ts" means
"Transportation Statistics". The source of the files is the US Bureau
of Transportation Statistics. The two digits are US Census Department
assigned AFIPS numbers for each state which you can find at their web
site. The last character is:
I - Interstate Highways
U - United States Highways
S - State Highways
O - Other Highways
If you keep your file sizes similar, your performance will be
similar. Unless you have a clean way to separate your polys by school
district or neighborhood or precinct, I would chop your files to
correspond to map tiles rather than in concentric circles.
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
