Filed Azure map - Only Render if a Slicer is Set

Hello Moehimby,

Hope you're doing well!

Stop trying to detect filtering via the fact table columns. Instead, measure the row count and use that as your gate:

IsFiltered = 

VAR SelectedZips = CALCULATE( DISTINCTCOUNT(fact_installs[ZIP]), ALLSELECTED(fact_installs) )

VAR TotalZips = CALCULATE( DISTINCTCOUNT(fact_installs[ZIP]), ALL(fact_installs) )

RETURN

IF( SelectedZips < TotalZips, 1, 0 )

Set your visual-level filter to IsFiltered = 1 as before.

Then :

1. Use ALLSELECTED correctly here

ALLSELECTED(fact_installs) respects slicer context from outside the visual. ALL(fact_installs) gives you the unfiltered universe. The comparison between the two is what detects "a slicer has reduced the set."

2. Set a threshold, not just < TotalZips

If your ZIP universe is 2M rows, even a state filter might still return 50,000 ZIPs and crash the map. Consider:

IsFiltered = 

VAR SelectedZips = CALCULATE( DISTINCTCOUNT(fact_installs[ZIP]), ALLSELECTED(fact_installs) )

RETURN

IF( SelectedZips <= 500, 1, 0 )

Pick a threshold your map can actually render (typically <1,000 ZIPs is safe).

3. The tooltip is fine and don't remove it

The measure in the tooltip is not the problem. The tooltip just exposed that the underlying filter detection was fragile. The fix above handles both cases.

Hope this helps! Don't forget to mark as solution and thumbs up in order to help others 🙂

I completely understand your frustration. Azure Maps is notoriously aggressive because it evaluates the location data pipeline separately from standard visual filters to build its spatial tile layers.

The reason your ISFILTERED logic breaks the moment you add [Average Stat] to the tooltip is because of Filter Context. Inside the Azure Map visual engine, it loops through every single ZIP code in your 2-million-row table to prepare the visual grid. When a measure like [Average Stat] is present in the tooltips, it forces a context transition for every row being evaluated. This causes your validation measure to see active filters where it shouldn't, failing the check and rendering the entire dataset until it crashes.

The good news is it doesn't have to be this complicated. Instead of trying to filter the visual container using a separate flag measure in the Filter Pane, the golden rule for stopping a map from rendering is to embed the filter logic directly inside the data measure itself, or force an empty result on the location field.

Here is the clean, human-designed solution to fix this permanently without causing any HTML validation issues on your forum post.

The Solution: Intercept the Location Data Stream

Instead of dropping the raw ZIP column into the Location well, you need to create a Secure Location Measure that returns blank if no slicer is selected. This forces Azure Maps to see zero rows before it even attempts to draw a boundary.

First, create this measure to handle your location routing safely:

Secure ZIP Location = 
IF(
    ISFILTERED(fact_installs[ZIP]) || 
    ISFILTERED(fact_installs[County]) || 
    ISFILTERED(fact_installs[State]),
    SELECTEDVALUE(fact_installs[ZIP]),
    BLANK()
)

 Next, clear out the raw ZIP column from your Azure Map's Location well completely, and replace it by dragging this new [Secure ZIP Location] measure straight into the Location slot.

Why This Fix Is Bulletproof With Tooltips

By shifting the logic directly into the location field evaluation, Power BI evaluates the slicer state before passing rows down the visual pipeline. If none of your three slicers are active, the Secure ZIP Location measure returns BLANK() for the entire table.

Because the map sees absolutely no location points to bind data against, it never executes the tooltip context transition loop for your 2 million rows, completely stopping the crash. The moment a user interacts with a State, County, or ZIP slicer, the conditional rule unlocks, allowing the map to render only the filtered, manageable subset of data seamlessly.

Hi Moehimby,

Thank you for sharing the update. That’s an insightful observation about the differences in behavior between explicit measures and implicit aggregations in Azure Maps.

Your findings will be helpful for others dealing with large datasets and similar rendering issues. Hopefully, Microsoft will enhance the visual’s performance and optimization in future updates.

Thank you.

Hi Moehimby,

Thank you for sharing the workaround you used.

Your insight into how Azure Maps handles very large datasets with explicit measures in tooltips is helpful. Noting that implicit aggregations tend to work more reliably in these cases will be valuable for others experiencing similar rendering and performance issues.

Pre-aggregating data in Power Query and connecting table fields directly to the visual is a practical way to enhance stability when working with high-volume geographic data.

Appreciate if you could share the feedback on our Microsoft Fabric Ideas. Which would be open for the user community to upvote & comment on. This allows our product teams to effectively prioritize your request against our existing feature backlog and gives insight into the potential impact of implementing the suggested feature.

Fabric Ideas - Microsoft Fabric Community

Thank you.