The usual advice for an OpenStreetMap Power BI integration involves heavy GeoJSON parsers, paid middleware or a Python script wedged in the middle. If your dashboard just needs a reliable map of specific locations, wild swimming spots or storefronts, that pipeline is over-engineered and your performance pays for it.
I thought I had seen every way a data model could break, and then I watched a client try to ingest the entire planet’s node list. Do not do that. Filter server-side with the Overpass API and bring the result in as a clean CSV. It is faster, it costs nothing, and it will not crash your Power BI refresh.
Overpass QL and tabular data
OpenStreetMap is a crowdsourced database as much as it is a map. Every object is a Node (a point), a Way (a line or polygon) or a Relation (a complex grouping). For a pragmatic OpenStreetMap Power BI integration, you do not want the XML or JSON bloat. You want a flat table, and Overpass QL lets you ask for exactly that.
The [out:csv] command tells the Overpass interpreter to return a semicolon-separated list, which saves you from writing nested JSON transformations in Power Query.
[out:csv(name,::lat, ::lon, image, description; true; ';')];
(
area["ISO3166-1"="PT"];
area["ISO3166-1"="ES"];
)->.iberia;
nwr[leisure=bathing_place](area.iberia);
out center;The query picks out the geographic area (Portugal and Spain), filters for “bathing_place” nodes, and returns the name, coordinates and metadata. The trick is out center;. Even when a swimming spot is mapped as a polygon rather than a point, you still get a single coordinate pair to plot on the map visual.
Refactoring the connection in Power BI
When you pipe this into Power BI, do not drop the URL into the “Basic” web connector. That becomes a maintenance problem later. Use Advanced mode and split the query into parts instead. Debugging gets much easier when you need to swap an ISO code or add another leisure tag.
Once the data lands in Power Query, the “Transform Data” wizard will often fail to recognize your headers, so apply “Use First Row as Headers” straight away. Server transients also cause intermittent refresh failures: when the Overpass API is busy, waiting is the price of free data.
If your trouble goes past maps into general data modeling, my guide on DAX filtering performance covers the measures that quietly drag a report down.
Visualizing GIS data with Azure Maps
For the visual layer, the Azure Maps visual is what I reach for in an OpenStreetMap Power BI integration. Drop the ::lat and ::lon fields into the Latitude and Longitude buckets, then add a DAX column to check data quality:
PhotoStatus = IF(ISBLANK('OSMData'[image]), "Missing", "Available")That lets you color the markers by whether anyone has contributed a photo yet, which turns a static map into a to-do list for field mappers.
One gotcha I have run into: Azure Maps sometimes will not redraw after a filter changes until you touch the map zoom. Messy, but resetting the slicer usually clears the state.
Building a solid data model here is much like handling custom calendars. If the foundation is flaky, the whole dashboard lies to you.
If this integration work is eating your dev hours, I take it on. I have been wrestling with WordPress and messy data pipes since the 4.x days.
Where to start
Perfect the query in Overpass Turbo first, then move it into Power BI through the Advanced web connector. Ship it, keep an eye on the refresh transients, and ignore the legacy GeoJSON advice that bloats a report. The data logic is the work here, not the middleware.
