question

balaautade-0225 avatar image
0 Votes"
balaautade-0225 asked SatishBoddu-MSFT commented

Get/Load all region faster by using Microsoft.Maps.SpatialDataService.GeoDataAPIManager.getBoundary

Hi Team, I have used Microsoft.Maps.SpatialDataService.GeoDataAPIManager.getBoundary to get the postal code boundary from Bing Maps. I have 2866 postal codes array collection that we pass to SpatialDataService.GeoDataAPIManager.getBoundary API and its take around 90sec to get all boundary in successcallback function of SpatialDataService.GeoDataAPIManager.getBoundary API. Is there any suggestion how can load all boundary faster in successcallback. Thanks, Vikas

azure-maps
· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hello @balaautade-0225 Just checking in if you have had a chance to see the previous response. If the response is helpful, please click "Accept Answer" and upvote it.

0 Votes 0 ·

1 Answer

rbrundritt avatar image
1 Vote"
rbrundritt answered

First thing would be verify if the requests are happening in parallel or not. If each request is happening one after the other has finished, then some improvement can be made. If they happening in parallel and you are creating a web app, then its likely the browser is throttling the requests. Typically browsers only allow 8 concurrent requests to the same domain at the same time. Which means that 8 requests will be processed in parallel and the rest will wait until those free up and when on request is completed, a new one will be created. This is most likely where your performance bottle neck is. One approach around this is to make these requests server side instead as throttling won't occur there. You could create a simple service where you pass in the array of postal codes you want, then on the server side you make those requests in parallel. Then return combine the results and return it to your app. This will mean your web app makes only one HTTP request so the browser won't do any throttling. This will increase performance significantly. If you want to try this out quickly, try using an Azure function as a quick way to create a simple service. https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-function-app-portal

Another approach to consider is to use Azure Maps. Azure Maps exposes boundary data slightly differently and allows caching of data. In Azure Maps you have to geocode your request first, and if there is a boundary for it, you will get a unique ID for that boundary which can be used to retrieve it from a separate boundary service. You could also geocode your postal codes on the fly using the batch service which would allow you to process up to 20 boundaries in a single request. That boundary service supports requesting multiple boundaries at a time which is equivalent to the approach I mentioned above with a custom service that makes the boundary requests server side. What you could do is geocode all your postal codes ahead of time and cache the boundary ID's, then in your web app, use the boundary ID's to retrieve the postal code polygons with a single request. Not only will this be faster due to the single request, but there will be less processing within the service since it is just doing a lookup by ID. Here are some related resources and samples:

https://docs.microsoft.com/en-us/rest/api/maps/search/postsearchaddressbatch

https://docs.microsoft.com/en-us/rest/api/maps/search/getsearchaddress

https://docs.microsoft.com/en-us/rest/api/maps/search/getsearchpolygon

https://azuremapscodesamples.azurewebsites.net/?sample=Search%20for%20boundaries

https://azuremapscodesamples.azurewebsites.net/?sample=Methods%20for%20geocoding%20multiple%20addresses

One last method to consider is to find an open data set of postal codes for your area of interest. If you can find open data and host it yourself as a flat file, that will likely be the fastest possible option.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.