Search code examples
geospatialstreet-addressazure-maps

Storing a structured address vs. a string for a user's address

I am diving in to using the Azure Maps service and while it can accept a StructuredAddress, it seems to prefer that it get the address as a string. In other words, it wants:

var addr = "15127 NE 24th Street, Redmond, WA 98052 US"

instead of:

var address = new StructuredAddress
{
    CountryCode = "US",
    StreetNumber = "15127",
    StreetName = "NE 24th Street",
    Municipality = "Redmond",
    CountrySubdivision = "WA",
    PostalCode = "98052"
};

So, not asking for opinions here, but what are the specific trade-offs here between the two ways of storing the data. What I can think of is:

String advantages

  1. DB schema - single column in the database.
  2. U.I. - free form single edit box is quicker/easier to enter

Structured advantages

  1. Get all components
  2. Clear what each component is

With either approach, when the user enters their address I will pass it to the service and then use the returned verified address.

So any other trade-offs?

Solution

  • If you are using the Azure Maps V2 Search geocoding service, behind the scenes it leverages the Bing maps geocoder. That geocoder is well known to perform better with freeform address strings than with structured addresses. This is documented in the Bing Maps docs here: https://learn.microsoft.com/en-us/bingmaps/getting-started/bing-maps-api-best-practices#use-the-find-by-query-api "The recommended method is to pass in addresses as single-line queries using the Find by Query API." where the "Find by Query" API is Bing Maps free form address string geocoder API. This insight hasn't made it into the Azure Maps documentation yet, I suspect because this API is still in preview.

    As for storage, what and how to store should be based on the needs of your scenario. If you need access to parts of an address, store that. If you need just the address string, store that. If you have users passing in address strings into a UI and want a cheap autosuggest based on addresses in your system, store the free form string. There is nothing wrong with storing both if you are fine with the additional storage space (likely relatively small unless you are working with tens of millions or more addresses, but even then, likely not a big cost. Also be sure to store the latitude/longitude value for fast loading/visualizations.