Location information can be very simple or very detailed. For a person delivering a package to certain house, an address with street number, name, city, and state could be more than enough information for them to find the right place. For a vehicle tracking system where you have a map with moving dots representing trucks in real-time, these pieces of data may not be enough to provide clear information to a dispatcher. Adding the latitude and longitude of the vehicle to present its current and historical positions is more important.
A very common scenario where the location data in place may not be enough to perform a certain task is when a company inherits or purchases a database of addresses to improve a process of their business. A retail chain may need to know where to put their next store to serve an undeserved population, a transportation company may need to find the best "green" route to create their truck schedule, or a sales company may need to define territories so that their salespeople can maximize their coverage to achieve better results. Independent of the scenario, having a database of addresses may not be enough to achieve certain goals, because important details could be missing.
In this blog post, I will show you how to create a database of simple addresses, how to enrich it and how to visualize the enriched dataset using Azure Maps.
In the following architecture we have two separate actors securely connecting to Azure via a web application hosted in Azure and an Azure Function, triggered on demand.
The Azure Function named Enrich addresses is responsible for searching for addresses without a geolocation (latitude, longitude) in the Azure SQL Server database. For each address, a call is made to the Azure Maps Search API, passing the address information as a parameter, and retrieving the geolocation to be stored in the database.
There is also a user accessing a web application that collects the locations from Azure SQL Server using the Azure Function Get addresses and generates a visualization layer with the Azure Maps SDK to present the addresses as points in a map. All traffic is handled via https and is encrypted with TLS.
Address enrichment logical flow
To enrich the database of addresses, the application makes a request to the database, querying for all addresses without geolocations. In return, it receives a list of addresses:
With the full list of addresses without geolocations, the application makes single calls with every single address to Azure Maps, calling the Search API. Azure Maps in response, provides the geolocation for that address. The response adds that information to the item and saves it locally. The Search API also provides extra properties in the response that are ignored by the application in this example.
Lastly, the application updates the addresses with their corresponding geolocations in the database.
Address visualization- Logical flow
The visualization layer contains a static web app, hosted in Azure, leveraging an Azure function to query the database for all addresses with geolocations. It then connects to Azure Maps to get the map tiles with dots representing the address.
Now we are able to present the information previously limited to text as geolocations in a map.
For a detailed step-by-step on how to create this solution, clone Fernando Rocha Silva's repository and follow its instructions.
Geocode storage considerations
In general, Azure Maps has specific terms of usage that I recommend reading before storing and processing the results.
Location data is powerful. When added to your analytics, it can provide valuable insight to corporations when making important decisions. Azure Maps provides a modern, secure and reliable cloud platform for any geospatial challenge that you may face.
In this blog post you learned how to enrich a database of addresses with Azure Maps by using the C# SDK within an Azure Function. You have also created a web page to visualize all results queries from the enriched database. For more practical and real-world examples, follow the Azure Maps Blog.