Most Power BI mapping problems do not start in the visual. They start earlier, when location data from a GIS file, business system, hosted service or generated geometry is used in an analytical report without being prepared for scale, interaction or browser-based rendering.
A spatial dataset may be perfectly valid in its source system but still unsuitable for a Power BI report. Reports are filtered, refreshed, published, shared and used interactively. They need location data that is spatially correct, model-ready, performant and reliable in the Power BI Service.
This guide explains how to prepare location data before it is used in the Icon Map visuals, from inspecting source data and checking coordinate systems to simplifying geometry and choosing the right output format.
What counts as location data in Icon Map?
Location data is often thought of as latitude and longitude fields. That is one common pattern, but it is only part of the picture.
In Icon Map, location data can include latitude and longitude fields, addresses or postcodes that need geocoding, WKT or GeoJSON geometry, Shapefiles, KML files, H3 indexes, origin and destination coordinates, route geometries, ArcGIS Feature Layers, WMS layers, raster tiles and vector tiles.
Preparing location data means preparing the data for the visual pattern it needs to support.
| Icon Map visual pattern | Location data needed |
|---|---|
| Circles | Latitude and longitude |
| H3 hexagons | H3 index or coordinates that can be aggregated |
| Lines or flows | Origin and destination coordinates, or line geometry |
| Routes or tracks | WKT or GeoJSON line geometry |
| Polygons or boundaries | WKT, GeoJSON, Shapefile, KML or feature layer |
| Reference overlays | Hosted files, ArcGIS, WMS, raster or vector tiles |
Inspect the source data before importing it
Location data is rarely ready for a Power BI report as-is. Before importing it, inspect both the geometry and the attribute table.
Useful checks include geometry type, number of features, number of vertices, file size, attribute fields, stable join keys, coordinate system, coordinate order, null geometries, multipart geometries, multiple layers and unnecessary styling or metadata.
For example, a boundary dataset might contain thousands of vertices per feature, unnecessary attributes, a name field that does not match the semantic model, a projected coordinate system and more precision than the report needs. The data may be correct in its source system, but still not prepared for a fast, maintainable Power BI report.
| File content | Likely Icon Map use |
|---|---|
| Point features | Circles, icons, clustering or heatmap |
| Dense point events | Heatmap, H3 or clustering |
| Lines | Lines layer or WKT line geometry |
| Boundaries | WKT or GeoJSON data layer, file data layer or reference layer |
| Multiple unrelated geometries | Split into separate Icon Map layers |
| Very detailed national geography | Simplify or tile before use |
| Managed GIS service | ArcGIS Feature Layer or WMS |
Check coordinates, coordinate systems and coordinate precision
Coordinate issues are one of the most common causes of blank maps, misplaced points and confusing results.
- Confirm that latitude and longitude fields are populated, numeric and in the expected order
- Check whether the values are decimal degrees or projected coordinates
- Confirm the coordinate reference system and reproject data where necessary
For WKT and GeoJSON, coordinate order is normally longitude then latitude. This is different from how many users casually talk about “latitude and longitude”, and it is a frequent source of errors.
| Data type | What to check | Icon Map use |
|---|---|---|
| Point coordinates | Values are populated, numeric and not reversed | Circles, icons, heatmap, clustering |
| Origin and destination coordinates | Both ends are present and use the same coordinate system | Lines, flows, routes, journeys |
| WKT point, line or polygon | Coordinates are ordered correctly and geometry is valid | Points, routes, territories and boundaries |
| GeoJSON geometry | Coordinates use longitude, latitude order | GeoJSON from data or hosted GeoJSON |
| H3 index | Resolution is appropriate for the report scale | H3 hexagon layer |
| Projected coordinates | Confirm EPSG code or reproject | Use EPSG configuration where supported, or prepare upstream |
| Address or postcode | Geocode before mapping | Convert to coordinates or geometry |
| Tile coordinates | Check URL pattern, zoom levels and hosting | Raster or vector tile layers |
| Coordinate precision | Match precision to accuracy, privacy and performance needs | Accurate, performant and appropriately anonymized maps |
More decimal places are not always better. For most Power BI reports, 4 to 6 decimal places is usually enough.
| Decimal places | Approximate precision | Typical use |
|---|---|---|
| 2 | Around 1 km | Broad regional analysis |
| 3 | Around 100 m | Town or neighborhood-level maps |
| 4 | Around 10 m | Most operational site maps |
| 5 | Around 1 m | Asset, property or delivery-level analysis |
| 6 | Around 10 cm | High-precision GPS-style data |
| 7+ | Centimeter-level or finer | Usually unnecessary for BI reporting |
Excessive precision can increase file size, make geometry heavier and imply a level of accuracy the source data may not actually have. If the data represents people, homes, sensitive assets or individual events, rounding or aggregating coordinates may be appropriate before the data reaches the report.
A common mistake is treating projected coordinates, such as British National Grid eastings and northings, as if they were latitude and longitude. The values may be valid numbers, but the map will place the data in the wrong location or not show it at all.
Clean attributes for joins, tooltips and formatting
Preparing location data is not only about geometry. The attribute table controls how the map connects to the Power BI model and how users experience the report.
Keep fields that support analysis and interaction, such as stable IDs, display names, categories, hierarchy fields, sort fields, join keys, tooltip fields, classification fields and status fields used for conditional formatting.
Remove fields that add weight but not value, such as unused metadata, duplicate columns, source formatting fields, long descriptive columns, unstable identifiers and internal fields that do not support analysis.
The best location data for Icon Map is not just spatially correct. It is also model-ready.
| Field | Possible Use |
|---|---|
area_id |
Stable join key |
area_name |
Display label |
parent_region |
Slicer or drill grouping |
category |
Formatting or legend |
sort_order |
Controlled display order |
status |
Conditional formatting |
tooltip_text |
Report tooltip content |
Validate and repair geometry
A shape can be good enough for one workflow and still cause issues in a Power BI report. Validation is especially important for polygon, multipolygon and line data.
Check for invalid polygons, empty geometries, multipart geometries, tiny sliver polygons, geometry collections, excessive coordinate precision and overly complex boundaries.
Invalid or unnecessarily complex geometry can cause missing shapes, blank layers, slow rendering, incorrect selections, unexpected hover behavior, tooltip issues, large files and poor Power BI Service performance.
Common preparation tools include
- QGIS
- GDAL/OGR
- MapShaper
- Database spatial functions
- Python notebooks
- DuckDB spatial processing.
A good practice is to repair a reporting copy of the data rather than overwriting the source of truth, unless that is part of a controlled data management process.
Simplify geometry for report performance
GIS-grade detail is not always report-grade detail.
A highly detailed boundary can contain far more vertices than a report user needs. In a national performance dashboard, a coastline or administrative boundary prepared for street-level inspection may add rendering cost without adding insight.
Simplification reduces file size and browser rendering work. The right level of simplification depends on the report scale, expected zoom levels and business question.
Always test simplified geometry visually. Over-simplification can make polygons look jagged or distort boundaries. Under-simplification can make the report slower than it needs to be.
| Use case | Geometry preparation |
|---|---|
| National overview | Strong simplification |
| Regional dashboard | Moderate simplification |
| Local operational map | Preserve more detail |
| Legal or regulatory boundary | Simplify carefully or avoid simplification |
| Large contextual geography | Consider vector tiles or tiled delivery |
| Data-bound polygons in model | Simplify enough to keep report interaction responsive |
Choose the right prepared output for Icon Map
Once the data has been inspected, cleaned, validated and simplified, decide how it should be delivered to the Icon Map visuals.
The same source data can lead to different Icon Map approaches depending on the analytical requirement. A territory boundary that needs to filter sales data should be a data layer. The same boundary used only as context could be a reference layer. A very large boundary dataset might be better simplified or delivered as tiles.
| Prepared output | Icon Map approach | Good for |
|---|---|---|
| Latitude and longitude fields | Circles, icons, heatmap, clustering | Sites, assets, incidents, customers |
| H3 index | H3 hexagon layer | Spatial aggregation and multi-resolution analysis |
| Origin and destination coordinates | Lines layer | Flows, journeys, depot-to-customer movements |
| WKT or GeoJSON in a table | WKT or GeoJSON data layer | Data-bound polygons, routes, catchments, generated geometry |
| Hosted GeoJSON | Data layer or reference overlay | Boundaries, regions, operational areas |
| Shapefile | Hosted or File-based data layer | GIS-supplied boundaries and areas |
| ArcGIS Feature Layer | Data layer or reference overlay | Managed enterprise GIS data |
| WMS | Overlay or background | Contextual raster information |
| Raster tiles | Background or reference layer | Custom basemaps or imagery |
| Vector tiles | Custom tile, background or reference approach | Large, detailed or multi-scale geography |
Decide where the prepared location data should live
Preparing spatial data is also an architecture decision. The format matters, but so does the location and ownership of the prepared asset.
In the Power BI model is best when geometry is directly tied to business data, filtering and selection matter, measures drive formatting, the geometry is not too large and the data refreshes with the semantic model.
Hosted as a file is best when geography is shared across reports, changes occasionally, is used as a reference layer and is maintained outside the semantic model.
Served as a service or tiles is best when the data is large, detail changes with zoom level, data is managed by a GIS or another platform, partial loading is needed or the map needs scalable context.
This decision becomes more important as reports move from Desktop testing to shared production use.
| Where should it live? | Use when | Risks |
|---|---|---|
| Power BI model | Interactive analytical geometry | Model size and refresh |
| Hosted file | Shared context or moderate boundaries | URL stability and CORS |
| GIS service | Data already managed by GIS | Authentication and availability |
| Tile service or archive | Large or detailed geography | Tile generation and hosting |
| Data lake or lakehouse | Upstream processing and enrichment | Usually needs publishing into a visual-ready format |
Do not let the URL become the weakest part of the map
A spatial file can be perfectly prepared but still fail in the Power BI Service if the visual cannot access it reliably.
Icon Map may need to fetch GeoJSON files, Shapefiles, KML files, PMTiles, raster tiles, vector tiles, WMS services, ArcGIS services or custom backgrounds.
For production reports, avoid temporary links and personal storage locations. Use stable URLs, version important assets, document ownership, test after publishing and check whether browser-loaded files require CORS.
https://icon-map.com/blog/hosting-with-cors.html
A map that works in Power BI Desktop but fails in the Power BI Service is often not a visual configuration issue. It is often a hosting, authentication, URL or CORS issue.
Test the prepared data in Icon Map
Testing is part of preparation, not a separate final activity.
Before moving on to advanced map design, confirm that the prepared location data behaves correctly in the visual.
Check that the layer appears in the expected location, all features are visible, joins match the Power BI data, selections cross-filter other visuals, tooltips show the correct fields and measures, conditional formatting behaves as expected and performance is acceptable with realistic filters.
Also test in the Power BI Service, not only in Desktop. Performance, filtering and accessibility problems often appear only after the report is published or used with real slicer combinations.
Common preparation problems and what they usually mean
When something goes wrong in Icon Map, the cause is often in the prepared data rather than the visual itself.
| Problem in Icon Map | Likely preparation issue |
|---|---|
| Points appear in the wrong place | Latitude and longitude reversed, or wrong coordinate system |
| Layer is blank | File access issue, invalid geometry, wrong field binding or filter context |
| Shapes appear in the wrong country | Projected coordinates treated as latitude and longitude |
| Boundary does not color | Join key mismatch |
| Some boundaries are missing | Invalid geometry, null geometry or unmatched data |
| Map is slow | Too many features, too many vertices or excessive tooltip/detail fields |
| Tooltips are empty | Missing fields or incorrect data binding |
| Works in Desktop but not Service | URL, CORS, authentication or hosting issue |
| Shapes appear but do not filter | Reference layer used instead of data layer |
| Routes look wrong | Incorrect origin and destination fields, or route grain |
| Polygons look too jagged | Over-simplification |
| Polygons are too heavy | Under-simplification or excessive coordinate precision |
| Points are too exact for the use case | Coordinate precision or privacy issue |
Prepare once, map reliably
Icon Map visuals can bring many types of spatial data into Power BI, from simple points to data-bound polygons, hosted files, reference overlays and tiled layers. The best results come when location data is prepared for the role it needs to play in the report: interactive analytical layer, contextual reference geography or scalable map asset.
Good preparation improves report performance, reliability, maintainability, user trust, Power BI interaction, reuse across reports, supportability and deployment success.
A well-designed map starts before the first layer is configured. It starts with location data that has been inspected, cleaned, validated, simplified, structured and tested for the way people will actually use it in Power BI.