Map block is issuing excessive geocoding requests

[Anandaroop_Roy]

I have recently configured the Map block on a few tables with a total of couple of hundred rows between them.

A few days later I checked my Google Developers console to see how my geocoding API key was faring, and I was shocked to see ~18,000 requests for that key.

If I open a Map block and the associated table simultaneously, I can see the geocoding cache column get updated repeatedly as I interact with the map — even though no data in those rows is changing. The gif below shows cell updates being triggered just while viewing/panning/zooming the map…

Then, if I open up one of records in question, I can see a bunch of changelog entries of the form: “User X edited this record using Map block Y”…

Can anyone explain what’s going on here? I’d like to keep using the Map block, but not if it’s going to blow up my API quotas simply by viewing the maps :frowning:

[Anandaroop_Roy]

Wow, my first post and I’m grateful for all the suggestions and discussion. Thanks!

Also, since it is in the the nature of things to pipe up when you are having problems — just wanted to also say that I am new to Airtable and generally loving it, including the Maps Block. One of the nicer solutions I’ve seen to get a table of location data geocoded quickly. Just need to get this over-geocoding issue sorted :slightly_smiling_face:

A few points, some in response to questions raised above

1. First of all, I’m going to start by doing a one-off copy of my calculated field into a dumb text field per @Bill.French’s suggestion — and point the Map Block at that. Let’s see if that nips the updates in the bud.

2. Remember that part of the problem here is not just the excessive geocoding, but also that attempt to update the row as well with the new cached geocoding value, thus spamming the edit history of each record. You’ll note from the 2nd image in my original post that the new value is always the same as the old value, thus defeating the purpose of having it cached in the first place, seemingly.

3. The actual formula I was using — turns out there were a couple of these formula columns in different tables.

• One was simply concatenating plain text fields and strings — CONCATENATE(Address, ", ", Neighborhood, ", Queens, NY") where Neighborhood is a Single Line Text field

• One was concatenating a fields, string, and references — CONCATENATE({Address or Cross Streets},", ",{Neighborhood (STRUCTURED)}) where Neighborhood (STRUCTURED) is a Link to Another Record field

• I think the perverse behavior I observed was entirely in the latter table, but I’m not positive.

4. Another thing I noticed is that I have multiple Map blocks referencing the same cache column, yet keyed to different location fields. That alone might explain some of the weirdness I am seeing. I can imagine that different users viewing different map views might end up clobbering cached data in this situation.

I’ll report back if I come up with any answers, and @Kasra I’ll follow up with support@ as well.

Thanks!

[Kasra]

Anandaroop_Roy:

I have multiple Map blocks referencing the same cache column, yet keyed to different location fields

Oh yea, that likely explains the behavior you’re seeing. Each map block stores the cached coordinates from the address field into the cache field. So if you have two maps with two different address fields, they’ll keep over-writing each others cache. In other words:

• The first map block sees “123 Sesame St” and geocodes it and stores it in the cache.
• The second map block notices that the cached value doesn’t match its address of “456 ABC St” so it re-geocodes.
• The first map block notices that the cached value doesn’t match its address of “123 Sesame St”, and so on.

[ScottWorld]

Kasra:

Oh yea, that likely explains the behavior you’re seeing. Each map block stores the cached coordinates from the address field into the cache field. So if you have two maps with two different address fields, they’ll keep over-writing each others cache. In other words:

Hi @Kasra, I only have one map block and I am seeing the exact same behavior. An extremely high number of API requests, just from adding one new record to a table.

[Kasra]

The best bet might be to email support@airtable.com so we can investigate more closely.

[Bill_French]

ScottWorld:

I only have one map block and I am seeing the exact same behavior. An extremely high number of API requests, just from adding one new record to a table.

A long time ago I thought I saw this and I wasn’t as thorough as @ScottWorld in sussing out the causal aspects. This was for a client and we needed to reverse geo-encode more than 25,000 locations. So I put a pin in that approach and went full API for mapping into Carto.

I resurrected that initial base and just verified, it is doing exactly what @ScottWorld is observing.

[ScottWorld]

I really hope that Airtable fixes this problem ASAP, because otherwise, this Maps Block will be of absolutely no use to my clients who have thousands of records in their system. Seems like it would only be useful for people with a small handful of records in their system.

[Bill_French]

ScottWorld:

absolutely no use to my clients who have thousands of records in their system

Yep - must be fixed - this is why we abandoned the idea of using Airtable maps for our project. This chart represents just 10 minutes of public transit locations reporting passenger flow. There aren’t many route stop locations, but there is a lot of activity and that’s when we noticed this overheating of the API calls.

[Anandaroop_Roy · Accepted solution]

Original poster here again, with an update.

TLDR my problem appears to be solved. To summarize:

• When I posted this, I was seeing my geocoding go haywire like this (33,000 geocoding requests!):

• I tore down all existing Map Blocks in my project

• I re-created, pointing the Map Blocks to purely static Single line text columns (created with a one-off copy&paste). That immediately nipped the problem in the bud, as expected:

• I then resumed using Formula columns, being careful to ensure that no two Map Blocks were referencing the same cache column, but with different location columns. Ultimately in my case I think that was the root of the pathological geocoding I was seeing, as suggested above (and maybe that condition might make for a good warning message in the product? cc @Kasra).

• API usage seems normal again. Note a small number of requests, corresponding to actually changed data:

I am cautiously saying that a Map based on a concatenated Formula column is now working as expected and will report back if that’s not true.

The only weird thing now, is that I unpredictably get this dialog once in a while in my Map Block. I worry that this is alarming/discouraging to my users and keeps them from using the maps. I can’t figure out the reason for this, no settings have changed in the meantime afaik:

[ScottWorld]

Not sure about that warning message! That’s strange.

That’s great to hear that your situation is temporarily working. Not sure if it’s going to stay permanently working, though. I say that because my system is setup 100% identically to yours, and I temporarily didn’t see any problems at first — and then all the same problems started happening to me shortly thereafter.

I reached out to support@airtable.com, and they said that they would investigate this issue.

If your solution breaks again, our only option for now will be to use external automations & websites to map our data. Kind of a bummer.