Hi, I want to assign the encoding points to the google map control in c#.net. Please send me any sample code for that.
On Fri, Apr 24, 2009 at 7:20 PM, mark mcclure <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
