Azure Maps: Getting Started and First Impressions

Since I’m heavily invested in Microsoft’s entire development ecosystem, I was ecstatic to get a glimpse of Azure Maps for the first time at 2018 Build. As I watched a presentation on it, my wheels were spinning on several ways we could leverage the technology. I’ll be writing later about some of the really cool stuff I’ve got planned for it but I first wanted to get my feet wet with a basic but somewhat interesting use case that would be implemented in our web and Xamarin apps.

Getting Started

True to fashion as other Azure services, getting started was as quick as creating an Azure Maps account in the Azure Portal and generating keys to be used in your REST calls.

A quick glimpse at the documentation yielding a few tutorials such as searching for a point of interest, routing to a destination and creating multiple routes.

Azure Maps Tutorials

These tutorials were great but something told me there had to be more to Azure Maps offering…..especially one that could meet my need.

My Use Case

Getting our users current location was useless for our need, so leveraging the user’s current longitude and latitude was out the window. Instead, we needed the location of where he/she spends most of their time. Asking the user for his/her city and state didn’t work either. Take a look at the below drawing.

Our requirement is to know which service center(s) our user belongs to. By use of the above relationships, we can always backtrack to know their locality and which client they are a part of.

What we didn’t want to do:

Present the user with long lists of service centers as we anticipate this number growing to hundreds/thousands

Have the user select their locality first to then filter the list of service centers. If you take the case in the drawing above; a user may inadvertently just select their state not knowing there is another option with their city or county.

Easily tell the world where we are providing services or who our clients were

How to accomplish all of the above:

My first thought was how can the use of a zip code help us. Of course, I knew zip code could get us to a city and state but if somehow it could narrow down further to a county that would be the jackpot. since many of our clients provide services that are limited to a county versus a city.

Can Azure Maps Help?

Here’s the point where I was looking for more from Azure Map. Digging further down in the docs I stumbled across the Search service which looked promising.

Azure Maps Search service

After spending about 10 minutes playing with all of the options of their REST service I ended up with a GET call like this

/search/address/structured/json?subscription-key={MAPSKEY}&api-version=1.0&postalCode=23234&countryCode=US&limit=1

Immediately I was impressed with the amount of info returned as well as the speed..about 200ms!

Sample results

Using my own zip code to test I was able to confirm the results. The freeformAddress field had the city, state, and zip; same as I would use for mail addressed to me. The municipality fields yielded other accurate city names that I’ve even used before as the city part of my address. The muncipalitySubdivision field was a surprise as these were actual neighborhoods in my area. This immediately got me thinking of future capabalities. Finally, countrySecondarySubdivision had the last piece I was missing…..the county.

Putting it all together

At this point, I was ready to code. I created a new route in our .NET Web API that took in the zip code as an input. The API then did a quick REST call to Azure to return a result set similar to the one above. Using the results we would determine the locality for the user to finally display a short list of service centers for them to pick from.

One caveat is in the case of my hand drawing where Client A serves the entire state of Iowa and Client B serves just Des Moines, Iowa. Our logic couldn’t inadvertently pick one client over the other but instead accurately pick the correct one and in some cases present a combined list of service centers to the user. To help accomplish this we added a great NuGet package called NRules , which is an open source production rules engine for .NET, based on the Rete matching algorithm. NRules prevented us from having a bunch of long and unreadable if/then or switch statements.

The first phase of our Azure Maps implementation is complete and I must say its very flexible, fast, detailed and just doesn’t have that “clunky” feel as that other geocoder that’s been around for years. More cool stuff to come!