U.S. Department of Energy’s Alternative Fuel Data Center
Hello OSM US, I am proposing to import the Alternative Fuel Data Center dataset, sourced from the U.S. Department of Energy.
Documentation
This is the wiki page for my import:
This is the source dataset’s website:
The data download is available here:
This is a file I have prepared which shows the data after it was translated to OSM schema (not the final file, a representation of what it will look like):
License
I have checked that this data is compatible with the ODbL.
This data is distributed under the Public Domain as a work of the U.S. Federal Government.
Abstract
This import will focus on Direct Current Fast Chargers (DCFC) in the United States that are open and available to the public. A python script will process the export using the AFDC API into OSM compatible tagging and combine multiple charge points into 1 overall charging station. This will process approximately 67,000 charge points into approximately 13,000 OSM elements. Once imported to JOSM, I will run conflation on existing OSM elements to update those that already exist and avoid duplication.
Please see the wiki page for this import for more detailed information.
13,000 items is more than will fit into a single changeset. Are you planning to break it up geographically to keep the bounding box from getting too unreasonable?
It would be wonderful to instantly add thousands of EV charging locations to OSM and, while it sounds quite enticing, the unspoken assumption is that the ADFC’s data is correct.
The USDOE AFDC doesn’t have the first one, has the second one, and has a bogus one just to the north of the second. I marked up a screenshot from the AFDC next to OSM:
Where their data came from I’m not sure, but we can’t yet trust it, but the proposal is to import it as if it’s all perfect. Bad idea. So, again, this is the second case of the very same false assumption about the validity of data to be imported. This would again result in the pollution of OSM, but with maybe double or triple the amout of bad data as from the 2025-06-22 bulk import from supercharge.info.
The data needs to be checked for validity, and if it’s valid, then import it. I don’t know if it’s technically possible with current tools, but if each edit could be checked for validity as part of the automated process (a “supervised” automated import, if you will), that would be OK.
Otherwise, much as I would wish it, I completely oppose any unsupervised automated import of AFDC data into OSM.
Thank you @TheNightRider for looking into this. The instant results an import promises are always tempting, and it is good for someone to do a reality check. Someone is probably going to say “what’s a handful of mistakes against thousands of good new chargers” but I, too, would err on the side of caution. Instead of importing, use the data to create a web site that shows “potentially missing chargers in OSM” and then let people add them individually after in-person checks. It takes much longer - but surveying is what we are about. We are not a third-party-data melting pot.
Exactly. I guess people sometimes think that because the government did it, it must be perfect. They forget that the government is made up of people and, like everywhere, there are very competent ones and incompetent ones. A single incompetent person can ruin a ton of work done by many competent people.
I like your idea of a “helper” website.
All I can say is we sure don’t want another boatload of bad data injected into OSM.
I would highly doubt that. Having a wrong station in OSM makes the user doubt all the other stations as well. I would agree, if we are talking about a couple of feet. Like the charger is easily visible from the wrong spot, for example instead of parking row 4 it’s in row 5 of the same lot.
But the sample above shows it’s not like that and it might be even a complete different parking lot. That’s not helpful for an EV driver to find the charger.
I would think it should be the other way round, you should verify your import data, proof to the community, that in general the data is within a couple of feet and the properties matching the reality.
So the question would be rather, which stations in your area did you personally verified?
It’s not like, I want to import data, please proof to me the data is wrong.
Edit:
In my area, that charger seems to be not in your data.
If I understand your map correctly, you plan to set a check date? At least the OSM-node does not have a check_date.
@GA_Kevin You’re doing some fallacious reasoning here. Let’s start with:
I’ve personally verified every charger in this import within about a 50 mile radius from me. All but one was spot on, with the one outlier being a few rows away.
You’re making the argument that because the data you checked in a 50-mile radius was good, therefore it’s all good. That’s like saying, “I saw a white fox yesterday and that’s the first fox I’ve ever seen, so all foxes must be white.” This is the fallacy of composition. If you had checked all data in a 7300-mi radius (Atlanta to Honolulu) and found it was good, that would be a different story.
@aighes is spot on. You don’t knowingly inject bad data into OSM and then fix it later unless you know exactly what is bad so you can fix. In this case nobody knows. It’s completely backwards to do a bulk import of it.
However, as @woodpeck predicted someone would say ("what’s a handful of mistakes against thousands of good new chargers”), you have just said that with:
What I mean to say is no data is perfect. The discrepancy in locations we’re talking a few rows of parking lots not miles apart. The benefits of having the station in OSM far outweigh the (rare) slightly misplaced node.
The facts are that nobody yet knows what the errors are in the AFDC database, and there might be other errors than position. In my L2 example, a bogus (completely nonexistent) station was in there. Waving that away as irrelevant L2 is indefensible.
As it turns out, so far 40 Supercharger stations have been found where the location error was over 100m. 5 were over 300m and one was almost 600m, almost half a mile. They’ve been fixed on OSM, but there might be more. It’s a work in progress that serves as an example of the dangers of auto-imports.
So, as suggested, get the data from the AFDC and compare it with OSM, adding or correcting as needed. But you can’t auto-import suspect data into OSM because you don’t have proof of its validity. As Carl Sagan said, “Extraordinary claims require extraordinary evidence” and you don’t have it. Nobody does.
I guess I don’t understand what’s so complicated here. These things are visible on overhead imagery, right? Just load them into the JOSM “TODO” plugin along with a sparse query of the existing charger nodes, and you can blast through hundreds of these things with manual review very, very quickly.
Sorry, but just because it’s the best available collective source doesn’t mean it’s good enough for OSM.
From OSM perspective every single bad data you import within seconds some human later on need to spend hours on fixing and until then annoys OSM users which are used to actually verified data.
The data in the Alternative Fueling Station Locator are gathered and verified through a variety of methods. The National Renewable Energy Laboratory (NREL) obtains information about new stations from trade media, Clean Cities and Communities coalitions, the Submit New Station form on the Station Locator website, and through collaborating with infrastructure equipment and fuel providers, original equipment manufacturers (OEMs), and industry groups.
with the possibility of user-submitted data:
Users submitting updates through the “Submit New Station” or “Report a Change” forms will receive an email confirmation of their submittal. NREL will verify station details before the station is added or updated in the Station Locator. The turnaround time for updates will depend on the completeness of the information provided, as well as the responsiveness of the station or point of contact.
and an intention to be accurate at a high level, but note the absence of the word “authoritative”:
NREL regularly compares its station data with those of other relevant trade organizations and websites. Differences in methodologies, data confirmation, and inclusion criteria may result in slight variations between NREL’s database and those maintained by other organizations. NREL also collaborates with alternative fuel industry groups to identify discrepancies in data and develop data sharing processes and best practices. NREL and its data collection subcontractor are currently collaborating with natural gas, electric drive, biodiesel, ethanol, hydrogen, and propane industry groups to ensure best practices are being followed for identifying new stations and confirming station changes in the most-timely manner possible.
If Kevin had hand-verified the entire AFDC dataset manually, it certainly would be a different story. It wouldn’t be a mechanical edit, so he’d be a lot freer to carry out the edits without this discussion. The bar for an import is certainly lower. One of the ways we build this community is by creating reasonable opportunities for others to fine-tune the data, but we need to do it thoughtfully. At any given time, we have a finite capacity to accommodate external data that needs cleanup.
Are the features in this 50-mile radius representative of the overall dataset? After all, NREL’s process sounds an awful lot like GNIS and The National Map Corps, which varies dramatically in quality from state to state, or TIGER, which can be perfect in one county and abysmal in the next.
Kevin, what’s the expected positional tolerance for the features you intend to import? A dataset that puts every charging station in the middle of the street would still be good enough for a lot of the statistical use cases AFDC highlights in their case studies, but that would be more embarrassing for us given our rendering and routing use cases. Both AFDC’s alternative fuel stations and historical datasets include a geocode_status field indicating the degree of precision, anywhere from GPS for presumably OSM-grade positioning to 200-1 for somewhere in the middle of Kansas. What’s the distribution of these values? Would you be open to limiting the bulk import to the highest-precision features, saving the rest for a later phase involving something like MapRoulette?
I haven’t reviewed the data to comment more specifically, but I agree with the general notion of segregating the data set into import, manual review, and discard piles.
Colorado has mirrored a subset of the data along with a more detailed description of the methodology, which can help us better understand the reliability of this data:
Each point on the map is counted as one station in the station count. A station appears as one point on the map, regardless of the number of fuel dispensers or charging outlets at that location. Station addresses are geocoded and mapped using an automatic geocoding application. The geocoding application returns the most accurate location based on the provided address. Station locations may also be provided by external sources (e.g., station operators) and/or verified in a geographic information system (GIS) tool like Google Earth, Google Maps, or Google StreetView. This information is considered highly accurate, and these coordinates override any information generated using the geocoding application.
Florida and Mississippi have done the same, along with a more detailed description of each geocode_status value:
Value
Description
GPS
The location is from a real GPS readout at the station.
200-9
Premise (building name, property name, shopping center, etc.) level accuracy.
Region (state, province, prefecture, etc.) level accuracy.
200-1
Country level accuracy.
200-0
Unknown accuracy.
These descriptions and the last digit of the value apparently correspond to an old version of the Google Maps API.[1] This doesn’t necessarily mean that the current data was geocoded directly using the Google Maps API. Maybe they just copied the schema before later adapting it with those extra descriptions of 200-5. But it does suggest that even 200-9 might still be what we’d consider subpar if it’s just somewhere in the same shopping center. It’s worth taking a closer look. We might want to focus first on GPS, which comes from an actual GPS readout and doesn’t have even the appearance of coming from any Google product.
Yes, please do. They have a lot of experience dealing with first-party sources and their caveats, even if the tagging isn’t going to be one-for-one.
Yes, but you need to do some due diligence to allay the concerns upthread. Can you do a spot check elsewhere, such as in the Denver area, in case there are regional differences? Try to get a sense of whether any positional errors you find correlate to a particular source, and whether geocode_status can mitigate those issues.
If the miscellaneous chargers are still useful to the public, maybe you could still turn it into a crowdsourcing effort using MapRoulette or even a collaborative spreadsheet.
Coverage in Canada comes from NRCan instead of NREL, potentially with different characteristics. Maybe approach Canada for advice about that.
