Blank maps overnight: our move to OpenStreetMap

At the end of September 2026, the maps on our sites turned into empty boxes. Everything else on the page was still there: the photos, the description, the property details. What had gone were the streets, the sea and the neighbourhoods, which is precisely the part of a property listing that answers the question «where is it?».

The cause wasn't a bug in our code. The map tile provider we relied on had started requiring an API key. Requests without one no longer got any images back, and without images a web map is just an empty frame.

What had actually broken

A map on a website is built from lots of small square images, called tiles, which the browser requests from a server as you pan around or change the zoom. The markers are drawn on top of the tiles. In our case, the part that drew the map was still working; it was the floor underneath that had disappeared.

The lesson is uncomfortable but useful: a service you haven't signed up for and don't pay for is still a dependency. We had treated it as part of the landscape, something that is simply there. In reality it had an owner, who could change the rules whenever they liked, and did.

The choice: get a key or change source

The quickest fix was to get a key and paste it in wherever it was needed. That would have dealt with the symptom, not the underlying issue. The rules had changed once without us seeing it coming, and they could change again.

We chose to move to OpenStreetMap. The data is open and maintained by a community, and the terms of use are spelt out plainly: you know in advance what is allowed and what isn't. For a group that builds its own tools, this matters more than any extra feature: we would rather have known, stable rules than conveniences that can vanish one morning.

Three sites and a filter

The switch affected three sites. The technical side of changing the tiles was the easy bit: you point the map at a different image source and it fills up again.

The real problem was aesthetic. The standard OpenStreetMap tiles use strong, saturated colours, designed for reading a road map, whereas our sites have a light, understated look. Next to the photos, the new maps looked as though they belonged to a different website. We applied a filter that lightens them, so the map stays readable but no longer shouts louder than the page it sits on.

A practical tip for anyone doing the same: lighten the background rather than the whole box, otherwise the markers fade too and you lose the very information you wanted to show.

From addresses to coordinates

Changing the tiles wasn't enough. To place a marker you need the property's coordinates, and we get those from the address using Nominatim, OpenStreetMap's geocoding service: you give it an address as text and it returns a latitude and longitude.

This is where our own shortcomings came to light, not the service's. The addresses in our listings had been written for people, not for a machine. They included flat numbers, staircases and notes added over time by whoever had filled in the record. To a human these are useful details; to an address search engine they are noise, and noise leads to wrong results or none at all.

So we cleaned up the addresses before passing them to the geocoder, stripping out anything that doesn't help find a point on the map. Flat numbers and staircases stay where they are useful, in the listing, but they no longer go into the coordinate search. It is unglamorous work and highly effective: a good share of the location problems was solved right there, before we had even touched the map.

The listing left without a marker

In the end, one listing was left without coordinates. The address couldn't be resolved: the geocoder couldn't find a reliable point.

We could have forced it, settled for the nearest result or placed the marker by eye. We didn't. Better no marker than a wrong one. People looking at a listing use the map to get a sense of the area, of how far it is from the sea, the centre and local amenities. A misplaced pin isn't a harmless inaccuracy: it is false information dressed up as precision. Its absence, on the other hand, honestly says «we don't know this for certain».

OpenStreetMap's rules, and why they suit us

OpenStreetMap asks for two things, and we have taken both seriously.

• Visible attribution. The map must show credit to OpenStreetMap and its contributors. It isn't a nuisance to be tucked away in a corner: it is the fair price of data that other people have collected and made available to everyone.
• Reasonable use of geocoding. Nominatim isn't designed to be queried every time a page loads. That is why coordinates are worked out once and stored with the listing, not on every visit.

The second rule, which exists to protect a shared service, has done us good too. Our pages no longer depend on an external call at the moment someone opens them: the coordinates are already there. If geocoding were slow or unreachable tomorrow, the maps would still show their markers. This is exactly the kind of fragility that left us with empty boxes, and we have now reduced it.

What we're taking away

• Every external service should be treated as a dependency, even when it is free and has worked for years without asking for anything.
• Rules written down plainly are worth more than convenience without rules.
• Dirty data should be cleaned at the source: a well-written address is worth more than any correction further down the line.
• Whatever can be calculated once should be calculated once and stored.
• A missing figure, openly declared, is better than a wrong one shown with confidence.

The maps are back. One of them has a marker fewer, and that's fine.