Understanding Layers in the Azure Maps Visual for Power BI

Australia is a map-heavy country to do business in. We have a handful of dense capital cities and then enormous distances of not much in between, so almost any dataset with an address in it tells a better story on a map than in a table. Store performance, delivery routes, service coverage, where your customers actually are versus where you think they are. The moment you plot that on a map, patterns jump out that a spreadsheet buries.

The Azure Maps visual in Power BI is the tool for this, and the thing that makes it genuinely useful rather than just pretty is layers. Once you understand how layers work, you can stack several views of your data onto one map and let people read it the way they read a real map. The Microsoft documentation on layers in the Azure Maps visual lays out the mechanics. Here is how we think about them when we build map reports for clients, and where things get fiddly.

What a layer actually is

A layer is one way of drawing your data on the map. The Azure Maps visual does not force you to pick a single style. You can turn on more than one layer at once, and each layer renders the same underlying data, or different fields of it, in its own way. Think of it like tracing paper stacked over a base map. One sheet has dots for each location, another shades regions by value, another overlays a bit of reference context. Together they make a single readable picture.

That stacking is the whole point. A bubble layer on its own tells you where things are and roughly how big they are. Add a reference layer underneath showing your sales territories and now the same bubbles tell you which territory is carrying the load. The layers do not fight each other, they compound.

The layers worth knowing

There are several layer types in the visual and they each answer a different question. You do not need all of them on every map, and cramming them all on is usually a mistake, but knowing what each is for lets you pick the right one.

The bubble layer is the default and the one you will reach for most. Each location becomes a circle, and you can size the circle by a measure and colour it by a category or a value. This is your bread and butter for "where are my things and how do they compare". Store revenue as bubble size, region as colour, done. It is the layer that most map reports actually need and the one people over-complicate away from.

The heat map layer is for density. Instead of individual points it shows a smooth gradient of hot and cold zones, so it is the right choice when you have a lot of points and what matters is concentration rather than any single location. Customer density across a metro area, incident hotspots, foot traffic. The trap here is using a heat map when you have thirty data points. Heat maps need volume to mean anything. With a handful of locations you just get a few blurry blobs that say less than plain bubbles would.

The reference layer lets you overlay your own custom geography, typically from a GeoJSON file. This is the one that unlocks Australian-specific reporting, because you can bring in your own sales regions, delivery zones, franchise territories, or council boundaries and plot your data against the boundaries your business actually uses. The built-in geography does not know your territory map. A reference layer does.

The tile layer lets you bring in an external map tile source and lay it over the base map. This is more specialised. It is genuinely handy when you have weather, aviation, or other domain map data published as tiles, and irrelevant for most business reporting. Do not go looking for a use for it. If you have one, you will know.

There is also filled and pie chart layer behaviour for showing categorical breakdowns per location, which is powerful but is also where map reports most often tip over into unreadable. A dozen tiny pie charts scattered across a map of Australia looks clever in a demo and confuses everyone in the actual meeting.

How we decide which layers to use

The question we start with is not "which layers are available", it is "what is the one thing this map needs to say". A map report that tries to say five things says nothing. So we pick the single primary message, choose the layer that carries it, and only add a second layer if it genuinely adds context rather than clutter.

A common good combination is a reference layer for your territories underneath a bubble layer for your locations. The reference layer gives structure, the bubbles give the data, and a reader instantly sees which territory each location sits in and how it is performing. That is two layers doing two distinct jobs, and it works.

A common bad combination is a heat map plus bubbles plus pie charts all at once. Each was added because it seemed useful in isolation, and together they turn the map into visual soup. When we review a client's existing reports, over-layered maps are one of the most frequent problems we find. The fix is almost always to remove things, not add them. This restraint is a big part of what we bring to the Power BI reporting work we do, and it is less about knowing the features and more about knowing which ones to leave switched off.

The Australian gotchas

A few things bite specifically when you are mapping Australian data.

Geocoding accuracy is the big one. The Azure Maps visual turns your addresses or place names into coordinates, and it is only as good as the data you feed it. Australian place names are full of duplicates. There is a Richmond in Victoria, New South Wales, Queensland, Tasmania and more. If your data just says "Richmond" with no state, the map may cheerfully plant it in the wrong one. The fix is to give the geocoder as much detail as you can, ideally full addresses or at least suburb plus state plus postcode, and to categorise your location fields correctly in the data model so Power BI knows a column is a state and not just text. Rubbish in, bubbles in the ocean out.

Performance is the second. Maps are heavier to render than most visuals, and a map with thousands of individual bubbles gets sluggish. If you are plotting a lot of points, a heat map often performs better and reads better than trying to draw every single point. Aggregating to a sensible level, suburb or postcode rather than individual address, keeps the report responsive.

The third is that the Azure Maps visual needs to be enabled at the tenant level by your Power BI administrator, and it sends data to the Azure Maps service to do the geocoding and rendering. In regulated industries or the public sector, that data residency question is worth checking before you build a whole reporting programme on it, not after. It is usually fine, but "usually fine" is not the same as "signed off by your compliance team".

Where map reports pay off

The industries where we see the most value from map reporting are the ones where geography drives the business. Retail chains working out catchment overlap and where the next site should go. Logistics operators looking at delivery density and route efficiency. Field service teams balancing technician coverage against where the jobs are. Real estate and property analysing markets suburb by suburb. In all of these, the map is not decoration, it is the analysis.

If your data has location in it and you are still reading it in a table, you are probably leaving insight on the table too. Layers are what take the Azure Maps visual from a novelty to a serious analytical tool, and getting the layer choices right is the difference between a map people actually use and one they glance at once.

If you want a hand building map reporting that says something clear rather than everything at once, that is exactly the kind of work we do. Have a look at our business AI and data services, or get in touch and we will help you get your location data onto a map that earns its space in the report.