Improvements have been made to standard GPolys since "fromEncoded" GPolys were introduced. The API does perform basic thinning of adjacent points. The ability of GPoly to deal with large polys is different today than it was a year ago.
Zoom strings are a basically flawed idea. Suppose two points are near each other. Zoom strings enable you to eliminate one or the other. Zoom strings do not enable you to average the two together. Zoom strings add approximately 50% to the size of the encoded poly package. Zoom strings could be derived "on-the-fly" in the browser without sending superfluous stuff over the wire. Doing it in the API reduces the chance of mistakes. Doing it in the API enables averaging between points. Doing it in the API also could benefit "on-the-fly" polys. Douglas-Peucker for zoom strings is overkill. By converting to pixels, it is easy to determine whether adjacent pixels will collapse into the same pixel at a given zoom level. The arithmetic is simple. It can be done in a single pass. The X & Y components ought to be considered separately. Douglas-Peucker just considers their combined distance. Douglas-Peucker was designed for polylines not for polygons. If applied improperly, it will produce erroneous results. If applied to Lat/Lon coordinates rather than to pixel coordinates, it will produce biased results. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" 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-API?hl=en -~----------~----~----~----~------~----~------~--~---
