Forum Discussion
Azure Map - Issue with Conditional formatting
I am using an Azure Map visual which is connected to a table which has my Line ID in Location bucket and values in the Size bucket. There is a shapefile which is connected as a Reference Layer which has the same Line IDs. The lines are picking up the geometry from the shapefile correctly as well. I have defined rules using a DAX to conditionally format the reference layer lines. However, in the rules there is no reference to a colour blue for 'Level 2'. But the conditional formatting applied is working for some features in my file, whereas for other features it is defaulting back to blue colour. The DAX is correctly assigning the value of Level 2 to the line as well as I have attached in the below screenshots.
Any idea on what is causing this/any ideas to troubleshoot this?
Hi v-abhinavmu and ShahRukhSameer
Thanks so much for your response and for the time you've taken to help with my query, I really appreciate it. I did try these approaches as well, but unfortunately, they didn't resolve the issue in my case.
After some further digging, I traced the problem back to the WKT/geometry of the shapefile I was uploading. Within the shapefile, the Line feature has a geometry type of MultiLineString. The Azure Maps visual does support MultiLineString geometry via shapefiles (and not other formats), so that part was fine.
The actual issue was that my Line had a disjoined geometry as a result of spatial processing. As you can see in the screenshot below, the Line is split into 3 separate parts whose ends don't connect.
Even though this disjoined Line still carries a MultiLineString geometry type, Azure Maps does not support disjoined features. The root cause turned out to be a cardinality/binding problem rather than a data problem: Azure Maps applies data-driven styling per feature. A LineString is a single feature (so it colours correctly), but a MultiLineString is one row holding N sub-parts, and the styling binder doesn't distribute reliably across them - so it drops the fill.
This also helped me rectify a related issue I was facing. I had been uploading the WKT geometry as a CSV, and none of the Lines were getting coloured. Once I geoprocessed the shapefiles to have a LineString geometry (rather than MultiLineString), I was able to upload the CSV as a Reference Layer directly — and the Lines rendered and coloured correctly.
Hope this helps anyone running into something similar!😄
6 Replies
- v-abhinavmu
Community Support
Hi FirzanaShuja,
May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you - v-abhinavmu
Community Support
Hi FirzanaShuja,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.Thank you.
- v-abhinavmu
Community Support
Hi FirzanaShuja,
Thanks for reaching out to the Microsoft Fabric Community forum. and thanks to ShahRukhSameer for sharing valuable insights.
Thanks for sharing the DAX and the additional details. Since the issue appears to be with how some of the reference-layer features are being displayed, I would focus on the reference-layer mapping and styling behavior documented for Azure Maps.
A couple of things would be worth checking:
• Unmapped Objects: Go to Format visual → Reference layer → Unmapped Objects and turn Show on. Microsoft documents that this highlights shapes in the reference layer that aren't mapped to any data points. If the lines that are displaying blue are highlighted, that would indicate that they aren't being data-bound as expected.• Identifier matching: The documentation states that Azure Maps matches the identifiers from the Location field with properties in the uploaded spatial file. If the spatial file contains multiple properties, Azure Maps uses the common property with the highest number of matches. So it would be worth checking which shapefile property is being used for the Link ID matching.
• Predefined styling: Check whether the spatial file contains any predefined style properties. Microsoft documents that predefined styles in the spatial file take priority over formatting configured in the format pane.
• Conditional-formatting priority: Microsoft documents the following priority order: preset styles in spatial files, unmapped-object colors, legend colors, conditional-formatting colors, custom formatting colors, and finally default colors. Therefore, if a feature is being affected by one of the higher-priority styling sources, the conditional-formatting color for Level 2 may not be the color ultimately displayed.
Given the behavior you're seeing, I would first enable Unmapped Objects → Show and check whether the features that are falling back to blue are being identified as unmapped. If they aren't, the next thing I'd check is whether the shapefile contains any predefined styling that could be taking precedence over the conditional formatting.
For more details, please refer to the below Official Microsoft documentation:
Add a reference layer to Azure Maps Power BI visual - Microsoft Azure Maps Power BI visual | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.- FirzanaShujaNew Member
Hi v-abhinavmu and ShahRukhSameer
Thanks so much for your response and for the time you've taken to help with my query, I really appreciate it. I did try these approaches as well, but unfortunately, they didn't resolve the issue in my case.
After some further digging, I traced the problem back to the WKT/geometry of the shapefile I was uploading. Within the shapefile, the Line feature has a geometry type of MultiLineString. The Azure Maps visual does support MultiLineString geometry via shapefiles (and not other formats), so that part was fine.
The actual issue was that my Line had a disjoined geometry as a result of spatial processing. As you can see in the screenshot below, the Line is split into 3 separate parts whose ends don't connect.
Even though this disjoined Line still carries a MultiLineString geometry type, Azure Maps does not support disjoined features. The root cause turned out to be a cardinality/binding problem rather than a data problem: Azure Maps applies data-driven styling per feature. A LineString is a single feature (so it colours correctly), but a MultiLineString is one row holding N sub-parts, and the styling binder doesn't distribute reliably across them - so it drops the fill.
This also helped me rectify a related issue I was facing. I had been uploading the WKT geometry as a CSV, and none of the Lines were getting coloured. Once I geoprocessed the shapefiles to have a LineString geometry (rather than MultiLineString), I was able to upload the CSV as a Reference Layer directly — and the Lines rendered and coloured correctly.
Hope this helps anyone running into something similar!😄
- FirzanaShujaNew Member
Thank you for looking into this.
I have tried checking the conditional formatting values. It is returning the expected value as shown in the tooltip screenshot. I have checked that and it is varying with different lines I am hovering over (as attached in screenshots below). Since I have kept a custom tooltip for the page, when I hover over the geometry, I am able to see the relevant Link ID as well.
The reason why I am unable to add the values as a table is because I am using a slicer so that my end-user can change the thresholds for the colour formatting, and the map will respond accordingly. (Attaching the screenshot of the slicers set below)
The reason why I believe the reference layer matches the link ID is because the tooltip response I am receiving is accurate. I am sharing the DAX I have set up for Link_Colour_Flag below for your reference:
Link_Colour_Flag =
VAR Start1 = MIN('Symbology Range - Link - Level 1'[Number])
VAR Start2 = MIN('Symbology Range - Link - Level 2'[Number])
VAR Start3 = MIN('Symbology Range - Link - Level 3'[Number])
VAR Start4 = MIN('Symbology Range - Link - Level 4'[Number])
VAR Start5 = MIN('Symbology Range - Link - Level 5'[Number])
VAR End1 = MAX('Symbology Range - Link - Level 1'[Number])
VAR End2 = MAX('Symbology Range - Link - Level 2'[Number])
VAR End3 = MAX('Symbology Range - Link - Level 3'[Number])
VAR End4 = MAX('Symbology Range - Link - Level 4'[Number])
VAR End5 = MAX('Symbology Range - Link - Level 5'[Number])
RETURN
SWITCH(
TRUE(),
AVERAGE([Value]) >= Start1 && AVERAGE([Value]) <= End1, "Level 1",
AVERAGE([Value]) > Start2 && AVERAGE([Value]) <= End2, "Level 2",
AVERAGE([Value]) > Start3 && AVERAGE([Value]) <= End3, "Level 3",
AVERAGE([Value]) > Start4 && AVERAGE([Value]) <= End4, "Level 4",
AVERAGE([Value]) > Start5 && AVERAGE([Value]) <= End5, "Level 5",
"Other"
)
- ShahRukhSameer
Continued Contributor
Hi FirzanaShuja,
I think the first thing I'd check is whether the conditional formatting is actually returning the expected value for each Link ID.
You could put the Link ID and your Link_Colour_Flag field into a simple table visual and see if you're getting Level 1, Level 2, Level 3, etc. for the correct links.
If that looks correct in the table but the Azure Map isn't showing the different colours, then it may be related to how the reference layer is handling the conditional formatting. In particular, if Link_Colour_Flag is a measure, I'd try using a column instead if that's possible.
For example, something like:
Link ID | Colour Level
8500005-870006 | Level 2
8500005-870007 | Level 3
8500005-870008 | Level 1Then use the Colour Level column for the formatting rules.
I'd also check that the Link ID being used by the reference layer matches the Link ID in your data exactly. Even small differences can cause the formatting to behave unexpectedly.
If you post the DAX you're using for Link_Colour_Flag, I can take a look at that as well. That may help narrow down whether it's a filter-context issue or something specific to the Azure Maps reference layer.