A station closes. The pumps come out, the canopy is sold, a car wash opens in its place, and for the next two years it sits on your navigation app as a perfectly ordinary fuel stop. This is not a bug in one particular app. It is a structural property of how nearly every fuel map on earth is built, ours included, and it is worth understanding before you plan a route around one.
What the underlying data actually is
Most fuel maps that are not owned by a fuel company are built on OpenStreetMap, a database edited by volunteers, published under an open licence. A fuel station there is a point or an area carrying amenity=fuel, decorated with tags describing it: name and brand, operator, opening_hours, self_service, payment:* for accepted payment methods, and a family of fuel:* tags for what it sells: fuel:diesel, fuel:octane_95, fuel:octane_98, fuel:e10, fuel:lpg and so on.
That schema is genuinely rich. You can express, in a machine-readable way, that a station is unbranded, self-service, sells E10 and LPG but not 98, takes contactless, and opens at six.
Now the important part, and it is a deliberate design decision rather than an oversight: the schema has no field for the current price, and no field for whether the fuel is actually there today. No pump status. No stock level. Nothing that changes hour to hour.
This is the right decision, and it explains everything downstream. OpenStreetMap describes the world's geography: things that are true for years. A price that changes twice a week and a queue that changes twice an hour do not belong in a geographic database, and every attempt to put them there produces data that is wrong more often than right. The consequence is simply that a map built only on this data can tell you a station exists and can never tell you it works.
Why closure is so much slower than opening
A new station gets mapped quickly. Someone drives past, notices something missing, adds it. The incentive is clear and the evidence is standing right there.
Closure has no such moment. Nobody drives past an absence. The building is often still there; the forecourt is still a forecourt; from satellite imagery, which is how a great deal of remote mapping is done, a closed station and an open one can look identical for years. The person best placed to notice is a local driver, and their most likely reaction is to stop using it and think no more about it.
There is also a correct-but-counterintuitive practice at work. Mappers are advised not to simply delete a feature that has stopped operating. Instead they apply a lifecycle prefix to the key, so a defunct station becomes disused:amenity=fuel while keeping its name. The vocabulary is precise: disused: means not currently in use but easily reinstated (over 530,000 uses across the database), abandoned: means still visible but in serious disrepair, restorable only with considerable effort (over 560,000), demolished: means actively removed (over 220,000), and construction: and proposed: cover things not yet open (over 180,000 and 210,000 respectively).
The reason for prefixing rather than deleting is sound: a deleted feature gets re-added six months later by somebody working from older aerial imagery, and the cycle repeats forever. Keeping the object with a lifecycle prefix records that a human looked and found it closed.
But this only helps if a consumer of the data respects the prefix. An application that queries for amenity=fuel without excluding lifecycle-prefixed objects will show closed stations as open. This is a common and quiet bug, and it is one reason two maps built on the same database disagree about the same forecourt.
The tag that tells you how old the data is
There is one more piece of the schema that almost nobody surfaces to drivers, and it is the most interesting one.
OpenStreetMap has a check_date tag: the date an object was last reviewed, written in ISO 8601 form, YYYY-MM-DD. It can also be scoped to a specific attribute: check_date:opening_hours=2021-05-13 records when the opening hours specifically were last confirmed. A synonymous tag, survey:date, leans more towards on-the-ground surveying. The app StreetComplete writes these tags as users answer its questions.
Its status is de facto rather than formally standardised, and the wiki is candid that there is no clear consensus on which verification-date tag to prefer, advising mappers to follow local convention. Which means the field exists, is widely used, and is applied inconsistently.
Still, the existence of check_date is an admission by the mapping community itself that a fact without a date attached is of unknown value. That is exactly the right instinct. The gap is that most maps built on this data never show it to you, so a station verified last week and a station last touched in 2016 render as the same identical pin.
What this means for you at the roadside
- Treat any pin as a claim about geography, not about service. It says a fuel station was here when somebody last looked. It does not say the doors open today.
- Distrust remote and rural pins the most. Density of mappers tracks density of people. A station in a large city gets corrected within weeks; one on a rural road may go unvisited by any mapper for years, and those are precisely the stops where being wrong costs you the most.
- Opening hours are the least reliable field on the object. They are tedious to record, change seasonally, and almost never get revisited. A station being open at all is a far safer bet than it being open at the hour the map claims.
- Brand is stickier than reality. Forecourts change operator often. A pin can carry a brand the site has not flown for five years, which matters if you are routing by loyalty card.
- Never plan the last leg of a tank around a single pin. This is the practical version of everything above. One unverified data point is not a plan; two candidates in different directions is.
What we do about it, and what we cannot
We use this data, so we inherit these limits. It is worth being exact about which parts we can fix and which we cannot.
What we cannot fix: we do not know, from map data alone, whether any given station is trading today. Nobody does. Any service that implies otherwise from the same source is overstating what it has.
What we do about it: we treat the geographic layer and the human layer as different kinds of fact, and we never blend them into one confident-looking pin. A station's location comes from the map. Whether it had diesel, what it cost, and whether the card reader worked comes from a driver who was standing there, and it is shown with the minute it was reported, so you can judge it yourself. That is also why we show no price rather than an estimated one. An old price presented without its age is worse than no price at all, because it invites a decision it cannot support.
The mapping community worked this out years ago and wrote it into the schema as check_date. All we have really done is refuse to hide it.