this may be a case for ignoring one of the fundamental tents of normlisation - perhaps it would nake sense to store your intermediate values int he table. after all its unlikely they are going to change from read to read (unless your cities are on mud slide or earthquake zones then its unlilkely tyhey are going to move).
index these intermediate columns.
not knowing what your application is you could also reduce the number of rows handled by the calculation by say imposing a crude filter
ie if you are looking for
then filter out the dreck by say returning rows with a latitude of 36.517 +/- n
and a longitude of -4.883 +/- n
-this wouldonly work if you are looking for a limited subset of data, obviuosly if you need all 8.5million rows to be examined then thats not going to do much good.
anything you can do to reduce the amount of work the trig fucntions the server has to do has got to be a bonus
Not knowing how the MySQL parser handles trig it may be better to pass what you can to the parser as numbers rather than function calls (for example it may by calulating the trig function each time - doubt it but y'never know [might be worth a try first off an see what difference if any it makes)
I'd rather be riding on the Tiger 800 or the Norton