Geocoding in the Power BI Azure Maps Visual - Getting Australian Locations on the Map

If you have ever built a map in Power BI and watched half your Australian data land somewhere in the North Atlantic, you have met the geocoding problem. It is one of the most common and most frustrating issues in Power BI mapping, and it catches people out because it looks like it is working right up until you notice Perth is in Scotland. Geocoding is the process of turning a text location, "Brisbane" or "4000" or "10 George St," into coordinates the map can plot. When it works you barely think about it. When it goes wrong it produces a map that is confidently, precisely incorrect.

I want to explain how geocoding works in the Azure Maps visual, why it is especially error-prone for Australian data, and what to do about it. Microsoft's documentation on geocoding in the Azure Maps visual covers the mechanics. What I want to give you is the practical version, the one shaped by cleaning up more than a few maps that dropped clients' stores into the wrong country.

What geocoding is doing under the hood

The Azure Maps visual can plot points two ways. If you give it latitude and longitude, it just plots them. No guessing, no lookup, the coordinates are the coordinates. If you give it text instead, a city name, a postcode, an address, it has to look up where that text is, and that lookup is geocoding.

To do the lookup well, the visual needs to know what kind of location each field is. That is the Data category setting, and it is the single most important thing most people never touch. You set a field's data category to City, State or Province, Postal code, Country, or Address, and that tells the geocoder how to interpret the text. Without it, the geocoder is guessing, and "Richmond" with no other context could be the one in Victoria, the one in New South Wales, or the one in London, Virginia, or several other places. It will pick one. It will not tell you it guessed.

This is the root of nearly every bad map I get asked to fix. The location fields have no data category set, so Power BI is doing its best with ambiguous text, and its best is often wrong for Australian place names because so many of them are shared with British and American towns.

Why Australia gets this wrong so often

Australian geography is a geocoder's worst case for a couple of reasons.

First, the shared names. Perth, Richmond, Newcastle, Melbourne (there is one in Florida), Sydney (there is one in Nova Scotia). A geocoder handed a bare town name with no country context will frequently resolve it to the northern hemisphere version, because those are often the larger or more commonly referenced places. So your Perth sales point cheerfully lands in Scotland.

Second, postcodes. Australian postcodes are four digits, and four-digit numbers are not unique to Australia. Feed "2000" to a geocoder without telling it the country and it has no reason to assume Sydney. It might not resolve it at all, or it might match something entirely unrelated.

The fix for both is context. Give the geocoder more than one field so it can disambiguate. A city field with a state field and a country field in the same visual gives the lookup enough to resolve "Perth, WA, Australia" correctly instead of gambling on a bare "Perth." Adding an explicit country column set to Australia, even a hard-coded one, is the cheapest insurance you can buy on an Australian map.

The approach I actually recommend

After enough of these, my advice is simple. If you have any volume of locations and you care about the map being right, get real latitude and longitude into your model and skip geocoding entirely.

Geocoding is convenient for a quick chart off a list of city names. But for anything you are going to ship and rely on, it introduces a lookup step that can be wrong, can change, and depends on how the text is written. Coordinates do not have those problems. A store at -27.4698, 153.0251 is in Brisbane today and will be in Brisbane forever, regardless of how anyone spelled Brisbane.

Getting coordinates is usually not hard. If you have addresses, you can geocode them once, in a controlled process during data preparation, check the results, and store the coordinates in your model. That is a completely different thing from letting the visual geocode ambiguous text live every time the report renders. One is a checked, one-off enrichment. The other is a guess that repeats.

When you do use latitude and longitude, set those fields' data categories to Latitude and Longitude, put them in the correct wells in the visual, and the map plots exactly where you tell it. No hemisphere surprises.

Where geocoding is fine, and where it is not

I do not want to be unfair to the feature. Geocoding earns its place in a few situations.

It is genuinely useful for quick, throwaway exploration. You have a spreadsheet of capital cities, you want to eyeball them on a map, geocoding by city name with a country field gets you there in seconds and precision does not matter.

It is also fine when your locations are coarse and unambiguous with context. Plotting sales by Australian state is low risk, because there are only eight and, told they are Australian states, the geocoder is not going to confuse them.

Where it falls down is precision and volume. Street-level addresses geocoded live are slow and error-prone, and the errors are silent. Large numbers of ambiguous points multiply the chances that some fraction land somewhere wrong, and on a busy map you may not spot the strays. And anything customer-facing or decision-driving should not rest on a live lookup that can quietly misplace points. If someone is going to allocate a delivery run or a sales territory off this map, the locations need to be right, not probably right.

The other quiet cost is performance and dependency. Live geocoding is a call out to a service. On a large model it adds time, and it means your map depends on that lookup behaving consistently. Coordinates in the model remove the dependency altogether.

My rule of thumb

For a quick look, geocode by name, but always give the visual a country and a state so it is not guessing, and always set the data categories on your location fields. For anything you are going to ship, get proper latitude and longitude into the model during data preparation, set those fields as Latitude and Longitude, and let the map plot exactly what you give it. The extra effort up front is nothing compared to the credibility you lose when someone in a board meeting points at Perth sitting in the Highlands.

Most of this is really a data modelling problem wearing a visual's clothing, which is why it comes up so often in our Power BI consulting work and usually gets solved in the data layer rather than the report. Sorting out location data, categories and coordinates is exactly the kind of foundation work that sits inside the Microsoft Fabric platform, and it feeds the broader business intelligence work we do, where a map is only trustworthy if the model underneath it is.

If you have got Power BI maps dropping Australian locations in the wrong country, or you want reporting built by people who get the geography right the first time, take a look at our services or get in touch.