Bulk import of Tesla Superchargers in the United States

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.

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!

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!

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!

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

1 Like

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.

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

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.

(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.

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.

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.

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

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.

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

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!

1 Like