Each time you enter a new address or change an existing address, AppSheet must send the address to the Google mapping service to convert the address to its corresponding latitude and longitude. This is referred to as "geo-coding" the address. Since LatLong fields already contain a latitude and longitude, they do not need to be geo-coded.
We send geo-coding requests to Google as quickly as possible. Google imposes limits on geo-coding to prevent overloading their mapping servers. After we make a number of geo-coding calls, the Google server may respond with a "rate limiting" error. When Google responds with this error, we use "exponential back off" between successive calls to the geo-coding service. For example, we might first impose no delay between calls to the geo-coding service. We make as many geo-coding calls as possible, using no delay. If Google responds with a rate limiting error, we impose a one second delay between calls. If Google responds with a second rate limiting error, we impose a two second delay between calls. If Google responds with a third rate limiting error, we impose a four second delay between calls. If Google responds with a fourth rate limiting error, we impose an eight second delay between calls, and so forth. As the delay increases each time Google returns a rate limiting error, it can take minutes, hours, or days to geo-code your addresses if you have hundreds or thousands of new or changed addresses.
Once your addresses are geo-coded, AppSheet caches the results on our servers to avoid the cost of geo-coding the addresses again.