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:

[Bill_French]

ScottWorld:

It only triggers the API when the address changes.

I think yours will re-trigger if you render the data in the UI. As I understand Airtable’s behaviour, if you never look at it, you’ll be fine. I have not created a test-bed to validate this.

Have you actually looked at your Maps API console to see how often it is updating? A small number of records would likely skate under the daily quota even if you were looking at it a bunch.

[ScottWorld]

Bill.French:

I think yours will re-trigger if you render the data in the UI. As I understand Airtable’s behaviour, if you never look at it, you’ll be fine. I have not created a test-bed to validate this.

I just tested this multiple times on my end.

I kept refreshing my Airtable database, I kept opening up my Maps block fullscreen and closing it again, I kept refreshing my web browser, I kept scrolling through the Maps block and zooming in & out, and I even double-clicked on several of the dropped pins on my Maps block.

Then, I checked my Google Maps API usage: 0 requests.

Then, I went back and added a brand new address into my Airtable base. I went back to the Maps Block and saw that the brand new pin was dropped on the map.

Then, I checked my Google Maps API usage: 1 request.

So, this is working perfectly on my end, and I am indeed using a formula field for my Address.

One thing that I didn’t check, and this is just out of curiosity on my end, is whether the Google Maps API was triggered as soon as I typed in the new address, or not until I scrolled to the pin on the map itself. I’m running out the door now, so I’ll have to check this curiosity later. :stuck_out_tongue_winking_eye:

[ScottWorld]

Wait, I’m back — I just couldn’t let my curiosity wait until later. Hahaha.

Okay, NOW I’m seeing the same problem as @Anandaroop_Roy!! This is so weird! I added ANOTHER new record, and this time around, I got 13 additional Geocode requests on my Google Maps API. This number 13 has nothing to do with the number of records in my Airtable base, so not sure where that number came from.

To be even more exact, I got:

13 additional Geocode requests.
2 additional Maps JavaScript API requests.

For a grand total of 14 geocode requests today and 3 Maps JavaScript API requests today.

Very strange!!

[ScottWorld]

Okay, I have a test table with only 4 records in it. I added a 5th record, and I got:

5 additional Geocode requests.
15 additional Maps JavaScript API requests.

And then, opening & closing the Maps block seems to OCCASIONALLY trigger 1 additional “Maps JavaScript API Request”, but not always. Although I can’t tell why or when.

Is this a formula issue? Or is this just how the Maps block communicates with the Google Maps API? Would the problem go away if the address field was 100% static?

This behavior really should be modified by Airtable — people can’t have Airtable chewing through their API limits like this.

[Kamille_Parks]

Bill.French:

However, like all feature requests that deal with a single missing dimension

And of course I prefer feature requests that tackle things from a big picture. This is a fundamental issue regarding an official, “standard” block: if you don’t have an address/set of coordinates in a single field it doesn’t work at all. That is an elimination of choice in an instance users would likely have had input values in separate fields, as is the case here as well as any time I’ve personally used the block. Map Blocks already do their own address parsing but at the roll of the dice of whether the user has put a full address in a compatible order. Other blocks already allow the user to set their own field mapping. The more consistent standard blocks are with each other, the better.

If the user already has “real” data, why is the Block designed to fit the data into a narrow box? All this discussion of when and where a formula should fire, why make them use a formula in the first place? Other blocks don’t and neither should Map.

The next time AT develops a block, I want them to ask themselves “Will this work right away, or do people have to do their own cleanup first? Can they do cleanup within the block itself?”

[Kasra]

@Anandaroop_Roy sorry about this, can you email support@airtable.com so we can investigate further?

[Bill_French]

We’re getting confused here - at least I am. Let’s summarize the points.

Kamille_Parks:

If the user already has “real” data, why is the Block designed to fit the data into a narrow box?

That’s just it; the user has real data distributed across many fields. Combining them via a formula field triggers the issue that @ScottWorld just verified.

I’m simply suggesting (as part of the remedy) that the user create a real field with the combined values. How he might achieve that requires (in my view) either an external process using the API, or an internal process using a script block.

The added observation is simply that this is one additional cul-de-sac that we see users driving into with formula fields. Formula fields tend to surprise users; this is just one of many and this one is a bit more egregious in that it can actually cost money for unsuspecting users.

If you believe the Map block itself is a (or the) problem, that’s a deeper dive that I’ll leave you and @Kasra to investigate; I’m simply offering a remedy to the user while tossing another log on the formula fields can create issues crusade. :winking_face:

Thanks @ScottWorld for verifying the issue - very helpful to know.

Last Point

When it comes to geo-location and any process associated with location science, I always help my clients avoid any features that magically geo-encode natively because I’ve learned that so few vendors design their solutions to be considerate of encoding quotas and costs. None of them has actually designed systems that allow you to control processing to stay within the daily encoding limits for free or any pricing tier. Given that Airtable is a low-cost data management solution, it’s in their best interest to defend customers from potential wasted encoding charges. Just sayin ’ …

[Kamille_Parks]

Bill.French:

Combining them via a formula field triggers the issue that @ScottWorld just verified.

Exactly. Separate street address, city, state, etc fields are common especially for records intended to be mapped, and the Maps block should have been designed to accommodate that. We shouldn’t have to use a formula in the first place.

[Bill_French]

Kamille_Parks:

and the Maps block should have been designed to accommodate that.

Perhaps - I certainly agree that had Maps Block provided one additional feature, this issue may never have arisen and I would have 90 minutes of my day back. :expressionless: Until, of course, the future Data Science block makes the mistake of doing this as well. :winking_face:

If you follow that logic, you are setting up the Maps Block developers and all other blocks developers who might perform API calls for whatever purpose across an unimaginable array of possible services - some with charges - to be aware that formula fields must be treated differently and/or that their solution mustn’t use formula fields and must, therefore, accommodate concatenations outside of the database.

Furthermore, the blocks developers would also need to test the data types of every field and they would have to support a collection of fields, adding further complexity to the configuration of the block itself. This would essentially require custom blocks to provide the formula layer externally; that’s a big ask.

This approach pushes the responsibility to address the wonkiness of formula fields from Airtable itself down into the hands of every custom script block maker. That seems like a bad policy following on the heels of an incomplete formula design. It’s a policy that places an unreasonable technical constraint and deep knowledge on the third-party community of developers. It’s simply added friction that will likely result in this issue popping up repeatedly while creating risks for users when someone building a block didn’t get the “memo” that formula fields sometimes go into Mad Max mode.

Architecture and design choices have deep consequences. I would recommend Airtable do exactly the opposite - remedy this issue at the head, not the tail because there are hundreds of tails and one head.

[Kamille_Parks]

Bill.French:

to be aware that formula fields must be treated differently and/or that their solution mustn’t use formula fields and must, therefore, accommodate concatenations outside of the database.

… I don’t see how you got such apocalyptic implications of switching the user interface of the Maps Block from a single field input to potentially multiple field inputs to match the interface of other existing blocks. Page Designer gets UI/functionality updates out the whazoo that only apply to that block, there’s absolutely no reason why Maps settings can’t get a new input/button or two. Nowhere did I say formula functionality shouldn’t be improved, but fixing formulas won’t address my complaint at all. Its a fairly simple request with exactly zero impact on other developers/blocks/scripts/API; Its not going to trigger some coding revolution by third-parties to unilaterally abandon formula fields. Not every complaint intrinsic to an individual block should have to be connected to some grand, all-encompassing api complaint to get addressed or even mentioned.

Its not like Airtable was going to go “Well we tweaked some design here, now we’ll never ever ever have to improve our formulas/scripting/API, time to shut down that department” lol