OK, thanks. I had a way to decode the lat/lon and wondered what the zoom string was buying me. The lat/lon compression is about a factor of 3 for Appalachian Trail etc. but you have to add in zoom string. 5 digits after decimal point is OK for most topo map applications, unless you're calling in a laser guided ordnance.
On Apr 6, 10:40 am, bratliff <[email protected]> wrote: > On Apr 5, 1:07 pm,ibgpsn<[email protected]> wrote: > > > Any plans to support encodedPolyline in v3? I have a lot of > > encodedPolylines! > > The old encoding algorithm has too many weaknesses. The "zoom string" > adds 50% to the payload without any benefit. It is confusing too. > Point reduction can be done quickly "on the fly" without using it. > The existence of the backslash character in the encoding alphabet is > the source of many errors. Accuracy is limited to five decimal places > which may not be enough in some applications. If the API were to > support it, it would be stuck with it indefinitely. > > You can use the following to decode your polys: > > http://www.polyarc.us/polyextract.js -- 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.
