Bulk import of Tesla Superchargers in the United States

Communities United States
61

Thanks!

No worries, if ref:supercharge_info is a helpful ID, then let’s use it! With the whole URL, as @Rovastar and you suggested, I’m all for putting that in the changeset comments unless you need it specially tagged.

It’s getting interesting because what is a brand? Tesla is the company’s short name and also their brand name, but they use Tesla Supercharger and just Supercharger as brand names. I checked a few months back, and they don’t have a trademark on Supercharger, maybe because the US Patent and Trademark Office knows that superchargers have been around to boost internal combustion engine power decades before Telsa, Inc. existed.

BTW, the reason tesla_supercharger was deprecated in favor of nacs for socket tags is because Tesla donated the technology to SAE for them to standardize, which they did as J3400. So Tesla does not own the technology anymore. SAE also slightly changed the name from Tesla’s original (North American Charging Standard) to North American Charging System. NACS is superior to older designs because the connector can transfer either DC or AC single phase power using the same two current-carrying contacts. That’s why it’s more compact than CCS Combo1 (aka CCS1) and CCS Combo2 (used in South America, the EU, and other countries). Here’s the worldwide connector chart I’ve been working on, last updated Jan 2025. The connectors are shown to scale. Note that there are a couple of question marks, because it’s not yet clear what’s going on in Japan and China regarding connectors that support both AC & DC. Maybe this is now known.

AC-DC_Worldwide_Charging_Connectors
AC-DC_Worldwide_Charging_Connectors1000×876 124 KB

Right, EVgo names their posts (another topic: who uses post and who uses dispenser? I just did a survey of that. Since Tesla and ABB use post, I’ll use it.) uniquely so when people contact tech support, they can tell them the name of the post with the problem. Tesla names their posts 1A,1B,1C,1D then 2A,2B,2C,2D and so on because each V3 and V3.5 charger cabinet powers 4 posts. Soon that will change to 8 posts powered by each V4 cabinet. So is 1A a name? I think right now it’s too much work of questionable benefit to tag each post, and there are now 70,000 global Supercharger posts. That’s just one company. It’s already hard enough to keep track of stations, and this can get to the “every blade of grass” level. So it makes sense from a maintenance workload perspective to name the station and tag it with capacity and sockets. Might be time for a proposal for the community to vote on.

No, none of the other tags were present (see my screenshots above or see the tag history). What was seen by the bulk import was the tag name=Tesla Supercharger, because the destination charger was mis-tagged as a Supercharger back in 2019. That set it up to be a match for the bulk import.

I think it’s OK for one or more posts to be tagged as a group as a charging station. What is a charging station? One or more posts. So a charging station can have 1 post or 100 posts. It doesn’t matter. What does matter is if 3 separate but identical posts are each tagged as 3 separate charging stations. That does not compute. What if there are different brands close together? Make each branded group its own station? Might be OK. As mentioned above, for stations that have all the same posts, I’d support tagging the group as a single charging station with the capacity and socket tags providing the number. That works well and is far less work than trying to tag every post. The other issue with trying to tag every post is how to even locate them. Already it’s hard to locate new stations and for that we need on-the-ground photos. Sometimes it will be 2 or more years before satellite photography is available, and then often it’s not good enough to tag individual posts.

Onward!

62

I can respond to the rest tomorrow (it’s getting late here) but we do have man_made=charge_point and it is available on the dispenser level from the Department of Energy AFDC. I couldn’t tell if you were suggesting we not tag dispensers. They provide valuable information on quantity of attributes that may vary per station such as output and sockets that may share all other traits. It’s also useful to tag the model and manufacturer of a dispenser because then we can run QA on it very easy by updating values based on that. I’d love it if I could just ask every mapper to look at nothing but the label. Tell me where each point is and what model it is and I can fill out dozens of tags on the dispenser and station that is useful!

Overall the issue you’ll see if you run that overpass query is mistagging what should be man_made=charge_points as amenity=charging_station. A charging station should have only 1 node or way for the station, and theoretically unlimited number of dispensers. Much like a single gas station can have many pumps. I think we agree on that though. When you run the query you’ll see the issue I’m talking about!

63

More tomorrow, too, but I did want to mention I did see one Supercharger station, somewhere in the US, that was double-tagged. By that I mean someone had tagged a node as a station, but someone else had mapped and tagged each post. I think there were 8 posts. What’s interesting is that I only saw the individual posts when editing, because Carto didn’t render the individual posts. Now I can’t remember if it showed up in iD or JOSM or both. I forgot which station it was, but I think it was an old one in California, back when a new Supercharger station was a super big deal. :sunglasses:

I can see benefits in tagging individual posts/dispensers, but I think it’s too much work right now when we first need to get the stations mapped. If we only had 100 stations in the entire country, that would be different. What do other people think about this?

Thanks again!

64

There is a discussion / issue on carto’s GitHub about this

1 Like
65

Overall, there doesn’t seem to be a very strong consensus about whether to use trade names or legal names in operator=*. However, NSI populated the operator tree with trade names at one point. I recall some discussions among NSI contributors about whether this was a good idea for pipeline operators, where most legal names represent a nested doll of shell companies. Legal names are more common for stuff like restaurant and hotel franchisees (which are typically entered by hand based on signs or receipts or whatnot). For a company as well-known as Tesla, the full legal name probably doesn’t add much value, especially since there’s also an operator:wikidata=* tag to eliminate any ambiguity.

(I moved the bulk of my reply to the new thread to stay on topic.)

Even physical addresses without mail delivery can have ZIP codes. I used to live in a college dorm that has a ZIP code of 94305 in its physical address, but this complex doesn’t receive mail from the USPS, only from private services like UPS and FedEx. I could only receive mail at the nearby post office, which is also at ZIP code 94305, but all the P.O. boxes there have a different ZIP code, 94309.

Whether I’m mapping a utility box or a building, I usually leave addr:postcode=* untagged unless I have some direct evidence of the ZIP code. If we have it from an external source, at least that’s better than someone inferring it based on nearby features.

Alternatively, we could create a data item for ref:supercharge_info=* and give it a formatter URL (P8). A data consumer could look up this data item by key ID and discover the URL format to apply. If supercharge.info ever redesigns their site, we can update the data item instead of having to do a bulk find-and-replace on every instance of this key.

Are addr:* tags for postal addresses only, or for locations in general?
Are addr:* tags for postal addresses only, or for locations in general?
66

Cool idea. Because sites do tend to get redesigned over time.

67

How reliable are the locations, in your estimation? Spot-checking around in my area, I see that many of the nodes in strip mall parking lots share an address with a shop on the other end of the parking lot. For example, this Tesla Supercharger is probably somewhere in front of this Safeway. There are a number of other addresses in between, so users could get pretty confused looking for either the charging station or the supermarket.

You and others have already corrected or recorrected some of these locations, but I think we should probably scoot the rest of the newer ones closer to a existing matching address, as an educated guess until we get access to updated aerial or street-level imagery. Pending the broader conversation about what gets an address, I’d suggest leaving the address tags on the charging stations (addr:*=* or object:*=*, doesn’t matter to me), so that we don’t lose information about where these POIs are supposed to be located. Then we can move any node that’s still on version 1 (or where version 2 was someone correcting a typo), and finally review higher-versioned nodes with a bias for reverting them to their previous coordinates.

68

(1) You ask “How reliable are the locations, in your estimation?” and then describe mapping errors on nodes in the strip center. I’m not quite sure what your question is, so let me try to unpack it. OSM is a community effort done by people with varying levels of expertise and care. You seem to be conflating the mapping errors of shops in the Safeway strip center with the Supercharger mapping I did. I had nothing to do with those strip center mapping errors. I only touched the Supercharger station, and I ran a JOSM Overpass QL search on my own username to verify it.

Others can be sloppy in their mapping, both with positions and tags (like incomplete addresses and misformatted phone numbers). I am the opposite. I don’t map something unless I have clear evidence that it’s there and have accurate info. The Supercharger station is for sure not in front of the Safeway, and in the Version #1 changeset I gave a reference to how I know that.

You obviously haven’t been to the station yourself or you wouldn’t even be saying what you’re saying, but there are at least 2 possibilities why you think the Supercharger is not where it is:

  1. You did not look at the reference I gave that points to a thread with street-level photos showing location.
  2. You actually did look at the reference, but you could not figure out the ground position from the street-level photos, and are now saying you need aerial imagery. That’s OK, and this is not a slight against you at all, but some of us have excellent 3D spatial visualization ability that allows us to use those street-level photos to get a ground position. We don’t need aerial imagery if the ground-level photos are good. It’s like being there on the ground yourself.

(2) I’ve been focusing on Tesla Supercharger stations, but have also mapped stations of other brands like EVgo, ChargePoint, and Electrify America. I got started with the new ones and then have gradually gone back in time to check existing ones. I’ve found position errors that came from initial estimates that didn’t get updated once a station went live. So somehow I’ve become Mr. Position. I started in Colorado because I live there, then branched out to other areas, mostly in the western US because I can’t do it all. There are a few out east that I’ve mapped because I know someone in the area or have some other interest in the area.

(3) When I map a station, I take the time to make sure of the location, and if I’m not sure I place a FixMe describing what the uncertainty is. Usually we are waiting on street-level photos to get a precise fix. When I don’t do a survey myself I rely on aerial imagery and street-level photos. I trust those photos because they’re from our community that exists to track this stuff. A few of us have drones, so sometimes we get drone photography that no map service on the Internet has. We need that and/or street-level photography because new stations take time to show up on satellite imagery, sometimes over 2 years, and we are not going to wait for that. There’s stuff on the ground and we’re going to map it.

(4) You are more than welcome to go to any number of stations and get a GPS fix and send it to me. I will update the map accordingly, but I bet the difference will be within a 10-ft radius. If my location is off, it won’t be off any more than anything else in an area. I do try to align the imagery baselayer every time I do any mapping, but often there’s no GPS locator point. Just today I was checking GPS traces, and they spanned the width of a 3-lane highway, so which one was correct? This is one of the problems we have in mapping, but I think it’s better to get something on the ground as best we can, then later if we get better GPS coordinates, we can update it.

(5) Another question about mapping charging stations is do you map them with a node or an area? The OSM wiki talks about this. Sometimes the station is made of several parts, such as this new one in Las Vegas. There are 4 separate areas with Supercharger stalls, so you’d have to do a relation of 4 areas (ways) to map this. I just placed a node in the approximate centroid of those 4 areas.

2025,0713_Supercharger,LasVegas,W_RussellRd_20Stalls+9L2_c2
2025,0713_Supercharger,LasVegas,W_RussellRd_20Stalls+9L2_c2475×282 41.6 KB

Right now, we’re trying to get stations mapped, and as of today there are 2715 in the US alone. It’s enough work just to place a node. If you’d like to help us out and start drawing ways and relations, go for it, but be sure to merge the existing node in with a way to preserve the history.

(6) I might be misunderstanding you, but if you’re suggesting we scoot things on the ground to match existing addresses, that is absolutely 100% backwards! You first map things on the ground, THEN you find the best address, not the other way around. Supercharger switchboard cabinets normally have an address on them, and that came from some local jurisdiction that hands out addresses. It doesn’t matter if the address is wrong. That can get changed, but something on the ground is in a fixed place and that’s job #1. Ground truth is the guiding rule: map what’s on the ground.

69

To clarify, I’m not questioning your mapping. I was wondering about discrepancies between POIs’ locations and their addresses in my admittedly localized sample. This had me concerned that the locations coming in from the supercharge.info or AFDC import – not your mapping – were imprecise and needed groundtruthing. However, I chose a poor example that this import had only moved a small distance and you had moved back. (The shops are correctly mapped.)

I had seen other chargers that you haven’t touched or that you had to move a greater distance. If it’s the case that these untouched discrepancies in the addresses are all consistent with the real world, then I agree that the addresses should not even be used as a rough draft for determining the actual location beyond what was in supercharge.info or AFDC. (I realize now that I’ve also gotten lost in all the different threads and imports by @GA_Kevin and conflated the supercharge.info and AFDC imports together.)

That said, I’m certainly not dead-set on blindly moving the POIs closer to addresses versus waiting until we have either groundtruth or better imagery. It was just a thought, but you clearly have a better handle on the state of these POIs than I do.

70

Thanks, yes, what happened is that the bulk import from supercharge.info had a couple of mistakes (which I had nothing to do with, found out after the fact, and I wish I had been involved because I could have asked questions to prevent the mistakes). One of the mistakes was assuming supercharge.info had the latest coordinates. Mostly it did, and when it didn’t the errors were usually small, but a few offsets were maybe on the other side of a parking lot (not like in the wrong town or something). Over the past year I’ve found a few of these and either mapped a nonexistent station on OSM or updated the existing OSM coordinates to a better position. Then I let the supercharge.info team know so they could update the coordinates on their database to match what I mapped on OSM. They use OSM as a baselayer, so it’s a nice confirmation to see the nodes line up. I had discovered and updated on OSM only a handful (maybe around 10-15), that I had not yet informed supercharge.info about, so those coordinates got overwritten with the bulk import. I already fixed those (I think), and we are in the process of going through all the stations to get all coordinates updated.

BTW, I haven’t planned on touching any of the EVgo, EA, or other brands that have gotten recently updated. If there’s another brand in the vicinity of a Supercharger, I’ll check it, but otherwise I have my work cut out for me just with the Superchargers.

The cool thing is, for Tesla Superchargers the teslamotorsclub.com forums are the source for most of the ground truth, street-level photography, and drone photography. It’s just a matter of using them (and now mining them for the older stations, though the older stations often now have satellite imagery available).

1 Like
71

Heh, heh, I know what you mean. I’ve gotten lost myself and might still be lost. :sunglasses: Maybe we need better thread management. Too many things in a thread make it unwieldy, and I probably made a long and unwieldy reply above.

72

For the sake of clarity and open learning, the “replace geometry” was by far the worst mistake on this import by me. I apologize for that, I should not have done that. I take full responsibility for that. In previous work on OSM EV infrastructure and work since I have not replaced geometry and that includes my weekly AFDC imports if existing OSM data is there.

4 Likes
73

Thanks! We all make mistakes and learn from them. Long ago when I was a student on a cooperative work assignment at a major manufacturer’s factory, I had a manager who said, “We’re doing stuff that hasn’t been done before, so if my people aren’t making mistakes, I know they’re not trying hard enough. Of course, we learn from those mistakes and try not to keep repeating them!”

The most embarrassing mistakes I’ve ever made are the ones I learned the most from and remember best. There’s an old saying, “The man who never makes a mistake is the man who never does anything.” So, I’m happy to have someone like you on the OSM team who’s passionate about the map and is looking for new ways to make it better.

Cheers!

3 Likes
74

I wanted to do a follow-up on the 2025-06-22 bulk import from supercharge.info and see where things stand. First, I wanted to give a little background.

Background on supercharge.info: what it is & what it is not

supercharge.info is a great resource that has always shown far more information on Tesla Supercharger stations than Tesla’s “Find Us” site ever has. It has data and map locations of planned sites, sites with building permits that haven’t begun construction, sites under construction, live sites, temporarily-closed sites, and even sites that have been permanently closed. It uses OSM as the basemap layer and places a simple color-coded pin for all sites. Tesla’s “Find Us” site has actually become comically unreliable for anything other than live sites.

There is one issue with supercharge.info, however: the lat/lon coordinates are often close but incorrect, mostly within 100m, but occasionally more. How did that happen? Initial locations are mapped from permits, construction plans, or the beginning of construction, but not revisited after a station is completed. People move on to the next new and exciting Supercharger location. A contributing factor is that it’s not important for EV drivers to know the exact position because, once a station is live, the car will route you to it. If it’s in the right parking lot, you’ll see it.

supercharge.info functions as a map for Supercharger discussions on TMC and also as an aid for trip planning and new station planning. Tesla regularly solicits suggestions from their customers for future Supercharger locations, and they hold a quarterly vote on new locations. supercharge.info is the best mapping tool to see the network status and gaps in it. It is not yet a precise map of Supercharger stations, but work is underway to do some serious groundtruthing.

What does supercharge.info have to do with OSM?

I had the idea to map stations on OSM in case something happened to supercharge.info. As I did this I noticed lat/lon position errors on supercharge.info, so I went back to the source of most of the data, the teslamotorsclub.com forum (TMC). This is where most people interested in Supercharger sites share plans, permits, photos, and other info. Some info and photos come in from Facebook, Twitter/X, Instagram, etc., but that gets linked to or copy/pasted into the TMC forum, making it the best single repository of this data. If supercharge.info disappeared tomorrow, it could probably be reconstructed from TMC. Interpreting the photos (mostly ground level, but a few drone shots) on TMC allowed me to get a better position for OSM. Stations older than a year or two now show up on satellite imagery, which makes it much easier to get a position.

However, on OSM we can’t be so cavalier about positions! So, after determining more accurate coordinates, I and others pass them on to the supercharge.info team who are on TMC, and then they update the supercharge.info database. I often update the position first on OSM, then tell the supercharge.info team after the icon shows up on the OSM basemap layer. Now I’m supplying lat/lon coordinates to make it easier for them.

What happened in the 2025-06-22 bulk import from supercharge.info and where are we now?

The 2025-06-22 bulk import from supercharge.info added some good data but also broke some good data and added some redundant data that had been removed a year earlier. The import was done based on a fundamental assumption that turned out to be false: all data were accurate

Here’s what went wrong:

  1. Some lat/lon coordinates were wrong. Some coords I had updated on OSM but had not yet told supercharge.info, and these were overwritten. Some of these, but not all, have been reverted. The supercharge.info team has been trying to get this sorted, and now there is a focus on getting better station positions for their entire database. However, there are over 2900 live or under-construction Supercharger sites that exist on the ground in the US alone.

  2. The bulk import didn’t check for stations mapped as ways vs nodes, and it didn’t check for existing stations mapped with minimal tags. The result is an unknown number of double-mapped stations. Sometimes it’s almost impossible to see because the lat/lon coords are identical. I initially discovered this by accident, and some have been fixed, but I just came across another station where it has not been fixed in Johnstown, CO:
    Someone before me mapped the correct station location as a way and then I touched it twice, before the 0622 bulk import, which added a bogus node nearby but off in a field. It’s off in a field because that’s where it was originally mapped at supercharge.info as the whole area was being developed, and after the site went live nobody checked it. Here they both are:

    3_Now2JohnstownSuperhargersOneIsBogus
    3_Now2JohnstownSuperhargersOneIsBogus1920×999 356 KB

    and here’s the info on the bogus node from the bulk import:
    4_BogusJohnstownNode_LatLon@SCinfo_HadNotYetBeenUpdated
    4_BogusJohnstownNode_LatLon@SCinfo_HadNotYetBeenUpdated1920×999 338 KB

    What’s odd is that GA_Kevin updated the good way afterwards, but didn’t delete the bogus node:
    5_GoodJohnstownWay
    5_GoodJohnstownWay1920×999 328 KB

    What has happened now is that Apple Maps, who tells us they import OSM data and give credit, now shows the bogus node. So now we have a cascading situation of garbage replication, even though you can clearly see the station away from the bogus node in the satellite imagery:
    6_AppleMapsImportedOSMdata
    6_AppleMapsImportedOSMdata1920×999 439 KB

  3. The redundant (and often out-of-date) brand:wikipedia and operator:wikipedia tags were removed in Jan 2024 by an automated edit by ZeLonewolf (Proposed bulk removal of brand:wikipedia tag from United States POIs). However, the bulk import from supercharge.info re-inserted those tags, and they didn’t come from supercharge.info. This means GA_Kevin was either a) unaware of the Jan 2024 deletion or b) decided to re-insert them despite community consensus to delete them a year before. Here’s an overpass turbo query showing the brand:wikipedia re-insertion:

    1-brand-wikipedia_TagsRepollutedOSM_in_0622_BulkImportFromSCinfo
    1-brand-wikipedia_TagsRepollutedOSM_in_0622_BulkImportFromSCinfo1210×889 178 KB

Conclusion
The community has been fixing the errors introduced by this automated edit, but I keep running into more, so I think it’s only fair that the user responsible for introducing the errors should fix them or assist us in fixing them until they are all fixed.

2 Likes
75

Hi @TheNightRider! I responded mostly on the AFDC import post but wanted to let you know I’ve merged all the nodes into the ways now to remove these duplicates:

76

Hi @GA_Kevin, thanks, that’s a good start, but issues remain:

  1. wrong lat/lon for Supercharger stations is an issue still with us. Are you helping to get good coordinates for the 2900+ live or under-construction Supercharger sites in the US? To accidentally inject bad coordinates and then walk away to leave cleanup to others is not quite fair.
  2. duplicate nodes on ways: fixed
  3. re-injected brand:wikipedia and operator:wikipedia tags still exist for 2525 nodes, 175 ways, and 3 relations as we see with another run of this query in overpass-tubo:
[out:json][timeout:25];
{{geocodeArea:United States}}->.searchArea;
nwr["brand"="Tesla Supercharger"]["brand:wikipedia"](area.searchArea);
out geom;

9-2025,0806-brand-wikipedia_TagsStillRepollutedOSM_in_0622_BulkImportFromSCinfo
9-2025,0806-brand-wikipedia_TagsStillRepollutedOSM_in_0622_BulkImportFromSCinfo1218×563 192 KB

  1. What about L2 Tesla Destination Chargers mis-tagged as Superchargers, like the one I found and fixed in metro Denver? There might even be other brands of chargers (both L2 and DCFC) that someone who didn’t know better tagged as Superchargers. Those would also have been touched by the bulk import. All this needs to be checked and verified.
1 Like
77
  1. I have shared with you a spreadsheet with this in private message. Please check. All stations further than a few hundred feet (100M) have been corrected. That is precise enough to call this a success to me.
  2. :tada:
  3. Will remove, prior to this I was unaware of that in the US and it didn’t come up until after. Should be a straightforward fix. Edit: This has now been fixed.
  4. This was not and never was a part of this import. I agree it’s a concern but perhaps one we need to look at in a different thread since it’s not related to this import.
78

Thanks, I’ve actually been editing that. Sent you a PM. I disagree that ±100m is good enough. ±2-3m is more like it, since we get Maxar satellite data with 0.3m resolution and GPS is around 0.3-5m accuracy (someone correct me if I’m wrong on GPS). What do long-time mappers say about the minimum position accuracy for OSM: ±2-3m? More? Less?

It unknowingly became part of the import because at least one mistagged charger got touched by the import. So, it’s directly related. I fixed that one but there are probably more.

1 Like
79

I’d have to agree that 100m is nowhere near accurate enough for an import. If you can’t get it accurate enough, then a direct import should be out of the question and other options should be considered (i.e. MapRoulette or a manual import alongside aerial/streetside imagery).

3 Likes
80

Hard to say in general and I would think it also depends on the direction and area. Like left/right side of the road should match but usually along the road 30ft accuracy would be fine in coarse mapped areas. In areas with high level of detail I would agree with your 10ft.

2 Likes