Forum Discussion
Azure Map - Issue with Conditional formatting
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!😄
Community SupportHi 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 Learn
I hope this helps. Please feel free to reach out if you have any further questions.
Thank you.
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!😄