Bing API

Added in Q2 22

From the Q2 22 software release, the original FastStats' drivetime algorithm is replaced by Bing's native Isochrone API endpoint in the Map tool. This calculates drivetimes on maps more accurately, and often significantly faster. The new method also provides options for calculating walking and public transport travel types.

Added in Q3 22

From the Q3 22 software release, the new Bing API endpoint is introduced into the calculations of the zones within the wizards. The two changes are:

The Point to Point wizard has been completely reworked to work effectively with larger numbers of records and, also, to allow the creation of drive-time nearest type virtual variables.
The Drive Zone wizard zones are now calculated using the Bing API endpoint and, consequently, are more accurate.

As a user, you have 6,600 annual Bing API transactions included with your FastStats licence. Messages displayed in the user interface ensure that you are aware of the number of transactions you will incur for a given piece of analysis. Transactions over and above the included 6,600 are subject to additional charges.

The two main types of billable transactions occur when:

Geocoding a location - i.e. finding where a location is. For example, if you specify a postcode, an API request is sent to Bing to confirm that the postcode is valid and then to identify its latitude and longitude.
Creating drive zones - when, for example, you want to see the area you can reach within a specified drive time of your selected centre point.

Added in Q2 23

Map wizards can potentially generate a lot of API calls. For example, let's consider that a retailer or event organiser wants to use the Drive Time wizard to calculate on a 'nearest' basis for 100 retail outlets or venues. If the maximum drivetime is 80 minutes, with a 5 minute accuracy, creating the virtual variable for this analysis uses 1600 transactions. If the variable then needs updating to add two new and remove two old locations, previously all the zones would be recalculated and a further 1600 transactions incurred.

From the Q2 23 software release, developments to minimise Bing transactions are introduced and a caching layer added which means:

Any zone created is stored
Any zone request is checked before creation and, if it already exists, the stored zone is reused

In the scenario outlined above, it means that only 32 transactions are incurred on the update of the 'Drive Time Nearest' variable.

The same applies for geocoded locations. If you have entered a location before, it is stored and reused. If you enter a location as latitude and longitude co-ordinates, FastStats recognises them as such and does not send the request to Bing for geocoding at all.

Finally, within the Location Geocoder wizard, if you specify that the information you are entering is a UK postcode*, the equivalent FastStats expression is used, rather than sending Bing API calls and incurring transactions.

*Only applies to UK postcodes.

Within the caching layer, there is the ability to set an expiry period after which you are prompted to confirm if you want to recalculate the zones, or reuse the stored ones:

Once you select 'yes' or 'no', a further dialog confirms the transactions required to proceed - for example:

Go to File > Tools > Options > Map to access and set your caching options: