On Apr 23, 10:55 am, Wally <[email protected]> wrote: > If speed & accuracy are important, look at: > www.polyarc.us/pack > www.polyarc.us/packer.js
It really depends on when you need the speed. In my experiments, packer encodes lines faster than the polyline encoder *but* the performance of the map after encoding is much better using the polyline encoder. Here's an example Encode: http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/EncodeAndPack/BritishCoastEncode.html Packer: http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/EncodeAndPack/BritishCoastPack.html Both of these map display the exact same data - an outline of the British coatline using about 50,000 points. Both of them are encoded "on the fly" to give you a sense of encoding times. Packer encodes in 12-15 seconds while the polyline encoder encodes in 20-25 seconds. Indeed, packer is faster at encoding. Now hit the zoom button once. The polyline encoder version changes levels in well under a second. The packer version changes levels in about 5 seconds. These tests were performed on my MacBook Pro Laptop running Firefox at 2.16 GHz. It seems to me that rendering speed after encoding is much more important than encoding speed, particularly when you have the option to pre-encode. The real way to improve encoding speed is to implement the encoding algorithm in a compiled language, like C. Then the encoding will run about 1000 times faster and this issue is moot. I wrote the polyline encoder in Javascript mainly because I knew that everyone in this group would likely be able to read and understand Javascript. Andrew contacted me and told me about some newer ports and I'll add those to the polyline encoding page. > It uses integer arithmetic for speed. It eliminates Lat/Lon > projection bias for accuracy. It has no function calls in the > main loop. It converges quickly with multiple pivots in the > same pass. It compensates for a Douglas-Peucker algorithm > deficiency (D-P was designed for polylines not for polygons). I don't get this. (1) In compiled languages at least, I expect floating point arithmetic to be the fastest available. Is there something about Javascript that makes integer arithmetic faster? (2) What's this Lat/Lng bias? The API expects Lat/Lngs. (3) Douglas-Peucker works fine with polygons, as the example provided here shows. Mark McClure --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
