Displaying your own geometries within the Power BI Visual

The OS Maps for Power BI visual provides two ways for you to display your own geometries in the Features Layer of the visual. This page explains the advantages and disadvantages of each method.

Importing data to the data model

If you follow the steps described in Importing GeoJSON or WKT to your data model you will be mapping geometries that are actually part of your Power BI data model. They will be provided to the visual by Power BI every time the visuals in the report are updated, in line with whatever slicers and filters are currently active.

Depending on how your data model is constructed, the geometries may be coming from some central repository within your organisation and so be kept up to date automatically along with the other data in your report.

The disadvantages of this approach are:

• There are stringent limitations imposed by Power BI on how complex the individual geometries can be.

• It can be quite complex to import your data to the data model if they are not already available there, and if you are not familiar with using GIS software to prepare the data.

Complex geometry limitations

This approach relies on having your geometry stored as a text field within your data model. There's a Power BI limitation where each field has a maximum size of 32kb. Any text longer than this will be truncated, and so the visual won't be able to display that feature it as it's incomplete.

Power BI does this truncation without any notification, but the visual does some checks, and if it believes it has been given truncated data by Power BI, a warning will be displayed in the notifications box.

Complex geometries with lots of vertices are quite likely to exceed this limit and so cannot be used with this feature - it works best with relatively simple features such as buildings etc. For more complex geometries, you may be able to simplify them, following the guidelines on this page. If this doesn't work, you will have to upload them directly into the visual instead.

Loading spatial data into the visual

The alternative approach is to load your spatial data from a file directly into the visual.

If you take this approach, you will be mapping geometries that are stored within the visual itself. The geometries do not become part of the data model, and Power BI itself does not "know" about them.

The visual remembers all the geometries, regardless of what data Power BI are currently sending to it based on current slicers and filters. It determines which geometries to show on the map based on looking up values of a field you specify in the data that Power BI provides to it.

This approach does not have the same limitations on geometry size that are described above, and it is likely to be more straightforward in many situations.

Because the visual has access to all the geometries, it also means you can continue to show them as "unmatched features" even if filters or slicers mean that their associated features are not currently being sent to the visual by Power BI.

However uploading data into the visual means that it is stored directly within the Power BI report file, rather than in the data model. If you have multiple copies of the OS Maps for Power BI visual in your report, each will store its own copy of any data you add to it.

Therefore, especially if you have multiple copies of the OS Maps for Power BI visual in your report, this can lead to larger report file sizes and be less efficient. Also, the spatial data will not be refreshed with the data model, they are simply saved from when you uploaded them.