return
Math.round(offset-radius*Math.log((1+Math.sin(y*Math.PI/180))/(1-Math.sin(y*Math.PI/180)))/2);
...
z=Math.sqrt(((z*z)/(x*x+y*y)));
z=Math.log(z)/Math.log(factor);
...
Integer arithmetic? A couple of month ago I ported adjust.js to Python.
Adjust.js is using the same kind of LtoXY things. Compared to
"classical" solutions for converting a lat/lon to an image coordinate
adjust.js was _dimensions_ slower... Didn't try this packer stuff in
comparison to others, but - where is the super fast integer arithmetic here?
Wally schrieb:
> If speed & accuracy are important, look at:
>
> www.polyarc.us/pack
>
> www.polyarc.us/packer.js
>
> 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).
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
