UK GOV Fuel Finder "Open Data"

Just saw this article on the BBC saying that petrol stations now have to report their fuel prices to publish fuel prices under the “Fuel Finder Scheme” within 30 minutes of a change.

The main website for this appears to be this page on GOV•UK.

Has anyone already looked into this from an OSM perspective?

Do we have an existing tagging scheme that might let us tag their information for this to allow OSM based apps to grab the relevant data?

I’m struggling to figure out what’s actually needed at the moment because I keep getting 403 forbidden when I try to read the docs on how their data’s retrieved.

5 Likes

What you get

  • current retail prices of all the petrol station by fuel type

  • forecourt details (address, operator, brand)

  • site amenities and opening hours

  • update timestamps for each price and site

Prices are published within 30 minutes of any change.

this sounds like a huge amount of stuff! if it’s under a good license it might be a good target for a bot that auto-updates OSM based on the published info

3 Likes

No explicit licence stated, just the OGL footer for the website itself. Given the history of “whoops, we accidentally found this was encumbered with OS rights” I would be a little wary of that.

OSM isn’t suitable for temporary, frequently-churning data like fuel prices. Opening hours and operator perhaps, but even then it’d be better done via conflation (as per @Robert_Whittaker’s tools) rather than an auto-updating bot.

6 Likes

As the owner of a classic car the piece of very useful information that doesn’t change is the fuel sold.

Since E10 appeared finding fuel when away from home has become a lottery.

I have added this tagging where I have been able to survey it however drive-by surveying isn’t easy because the price of premium E5 is never advertised on the sign.

E10 in my 49 year old classic would cause expensive damage, even in my modern car it is not recommended by the manufacturer.

3 Likes

Looking through the CSV file published https://www.developer.fuel-finder.service.gov.uk/access-latest-fuelprices it looks like each petrol station has a unique ID (forecourts.node_id), which could potentially be tagged in OSM to allow apps which use the data to query the API?

Here’s an example row from the data:

latest_update_timestamp: Thu Jan 29 2026 16:04:28 GMT+0000 (Coordinated Universal Time)

mft.name: TESCO STORES LIMITED

forecourts.node_id: 4882e3fee979cfefa29a8777ce57ca0ecea27b4f12ba7fb538ed0855d6b0af1c

forecourts.trading_name: PONTYPOOL SUPERSTORE - PETROL FILLING STATION

forecourts.brand_name: TESCO

forecourts.is_motorway_service_station: FALSE

forecourts.is_supermarket_service_station: FALSE

forecourts.public_phone_number: 448003000000

forecourts.temporary_closure: FALSE

forecourts.permanent_closure:

forecourts.permanent_closure_date:

forecourts.location.postcode: NP4 6JU

forecourts.location.address_line_1: LOWER BRIDGE STREET

forecourts.location.address_line_2:

forecourts.location.city: PONTYPOOL

forecourts.location.county:

forecourts.location.country: WALES

forecourts.location.latitude: 51.70007

forecourts.location.longitude: -3.04025

forecourts.fuel_price.E5:

forecourts.fuel_price.E10: 126.9

forecourts.fuel_price.B7P:

forecourts.fuel_price.B7S: 135.9

forecourts.fuel_price.B10:

forecourts.fuel_price.HVO:

forecourts.opening_times.usual_days.monday.open_time: 00:00:00

forecourts.opening_times.usual_days.monday.close_time: 00:00:00

forecourts.opening_times.usual_days.monday.is_24_hours: FALSE

(A bunch more columns for opening hours)

forecourts.amenities.fuel_and_energy_services.adblue_pumps: FALSE

forecourts.amenities.fuel_and_energy_services.adblue_packaged: TRUE

forecourts.amenities.fuel_and_energy_services.lpg_pumps: FALSE

forecourts.amenities.vehicle_services.car_wash: FALSE

forecourts.amenities.air_pump_or_screenwash: FALSE

forecourts.amenities.water_filling: TRUE

forecourts.amenities.twenty_four_hour_fuel: FALSE

forecourts.amenities.customer_toilets: TRUE

Whilst some of that might be useful, I’d be a bit wary of data quality too - I’m surprised that a “TESCO” named “PONTYPOOL SUPERSTORE - PETROL FILLING STATION” has forecourts.is_supermarket_service_station: FALSE :slight_smile:

1 Like

Well obviously that’s a superstore not a supermarket. :stuck_out_tongue:

The forecourts.node_id looks a bit unwieldy for something that other apps providers may want to use. I wonder if it’s stable.

Nice to see actual latitude and longitude though.

2 Likes

I actually know that tesco’s since it rather close to me. the fuel station is not really on the same site as the supermarket. its basicly behind the shop and completely isolated. maybe is_supermarket_service_station is used for when the fuel station is part of the super market’s car park with a shared entrance and exit

2 Likes

The data in Australia is provided (at the state level) via SmartPhone apps.

It has the various grades of petrol and diesel but also treats EV charging, LPG, hydrogen, etc as a “fuel”, so it is useful to all drivers. Perhaps the UK data does as well?

Yep all that is available but in different places as under different regulations:

As this topic is about petrol and diesel I’ll stay focused on that. My view is that there is value in the new data (fuel types and maybe some other bits) so a well thought out approach has my support.

I’ve managed to access documentation and have a Client ID and Secret, but every API request for an API token I’m getting a 403 error.

I’ve looked at the CSV data and it looks like it needs a bit of tidying up; for example some users have input the fuel price in pounds £1.339, others in pence 133.9p and others in tenths of pennies 1339

3 Likes

Has anyone found a formal specification for either the input data being supplied or the CSV file fields? It would be good to know what data is supposed to be there and how it should be formatted, and then perhaps we can start submitting reports about errors.

(In particular, the brand column looks a little inconsistent, the addresses look to be mostly in all-caps, and who on earth came up with those ridiculous IDs?)

3 Likes

They seem particularly obtuse given that the regulations @RobJN linked above say:

And that the aggregator must also provide a way to supply the price update information by:

If that long string of nonsense is the official registration number than the chance of successfully typing it into a touchtone phone or even successfully reading it to someone within the half hour limit seems slim to none.

If it isn’t the official registration number … then why are there two IDs for the same fuel station?

1 Like

The CMA has forced similar data released for a number of years now. As a precursor to this dataset.

Anyway, having used the CMA data, we are basically perfect for coverage of fuel stations across the country. Brand correctness is pretty good too, but not perfect. fuel:* is not good, but B7, E10, E5 and SDV data is available to anyone who wants to add it.

Matching the CMA data to OSM is easy enough, I don’t think we need to waste our time adding refs and maintaining them for the vast majority of fuel stations. If someone really needs pre matched data, OSM UK could potentially do it.

Fuel prices are way to dynamic to be in OSM.

So it’s gone from a small scheme where you could easily download some geoJSON files to something “open” we’re 403 Forbidden from accessing.

“Beware of the leopard” I guess.

1 Like

An API is fine for the intended users (app developers who want to pull in data automatically) with authentication in place to ensure the system stays up for all and is not taken down by a rouge app submitting excessive requests. Am not sure why it 403 errored for one user (user error? Account not fully approved yet?) but doubt that is the case for all.

The CSV is an alternative option.

The CMA data wasn’t geojson and wasn’t perfect. Some providers blocked access via Cloudflare so you could only load the JSON in a web browser. But yes, it was significantly more accessible.

And I don’t think the new data is Open Data…

Terms and conditions of access

By registering as an Information Recipient you are agreeing to the terms and conditions of the Open Government Licence as well as the Fair Use policy of the Aggregator.

The Aggregator Fair Use Policy:

Fuel Finder provides the option to access “near real-time” price updates. If you are using either the CSV or API for any purpose that promotes fuel retail opportunities to the motoring public, you must agree to utilise the most up to date CSV, or to call the API with a frequency that on average in a single day is not more than 5 minutes so as to prevent the price information presented to the public from differing materially from that within the Fuel Finder Service database.

You may not amend or hide price information to artificially promote or hinder the market prospects of a motor fuel trader, nor present a false image of the fuel retail ecosystem.

You must include either a link to Report a Discrepancy or provide feedback to the aggregator of complaints received on your own platform about the fuel price information as sourced from Fuel Finder.

When using data obtained from the Fuel Finder API, you must:

  • Present fuel prices in an unbiased manner
  • Not manipulate, filter, or selectively display data to favour certain suppliers
  • Not misrepresent prices or create misleading comparisons
  • Ensure that any price comparisons are based on objective criteria
  • Use the data as provided without modification that could mislead consumers
  • Not alter timestamps or other metadata that could affect data interpretation

Exceptions for events beyond Reasonable Control

Users will not be considered in breach of this Fair Use Policy where failure to comply results from circumstances beyond their reasonable control. Such circumstances may include, but are not limited to, unplanned technical outages, failures of third-party systems or networks, power outages, natural disasters, acts of government, or other force majeure events.

This exception applies only for the duration of the relevant event, provided the user takes reasonable steps to mitigate the impact and resumes compliance as soon as reasonably practicable.

The Aggregator reserves the right to:

  • Monitor your use of the API to ensure compliance with these terms
  • Suspend or terminate access if you breach these conditions
  • Request evidence of compliance with fair representation requirements
  • Investigate complaints about misuse of the data
  • Throttle access when required to maintain service performance

Breach of these terms may result in:

  • Immediate suspension of API access
  • Permanent termination of access rights
  • Reporting to relevant regulatory authorities

By continuing you are agreeing to this Fair Use Policy for using the Fuel Finder API.

You couldn’t, for example, prioritise brands with net 0 plans

  • Not manipulate, filter, or selectively display data to favour certain suppliers
2 Likes

Just to put another perspective on this and not wanting to dampen enthusiasm but why does OSM need to replicate another functioning service.

For “mapping” OSM brings together data collected by the community within a central resource that is not available elsewhere or it is only available on commercial sites.

If the Govt’s site works ok it seems an unnecessary duplication to represent it in OSM. If the Govts system doesn’t work or significant advantages can be had by presenting it in a different and more usable format I can see the point. We seem to be acting with an attitude if its there we can use it – a bit like a conglomerate wanting to conquer the world as opposed to providing a benefit to the community as a whole.

1 Like

But you can get the CSV file without needing to “register as an Information Recipient”. So can you just ignore everything apart from the OGL if you just use the CSV file? (With the acceptance that you only get twice daily updates.)

4 Likes

If nothing else it can help ensure we are not missing objects or showing ones that no longer exist.

Also OSM gives geographical context and makes it easier to navigate than an address.

6 Likes