Bulk import of Tesla Superchargers in the United States

[TheNightRider]

@GA_Kevin

Dang @TheNightRider you’ve been busy!! Solid work!

Thanks!

@GA_Kevin

I have no issue if you want to go through and add something like ref:supercharge_info:source and have it be the whole URL, I just ask that we keep ref:supercharge_info as the ID as we are doing analysis and updates with that value and that corresponds directly to the ID in the Supercharge.info database. So it is useful for more than just a nice link to have the ID separate

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.

@GA_Kevin

RE: Brand vs Name
Most every EV charger does not have a name, and very, very few stations in the US do. Every Supercharger in the US displays the brand which is Tesla, not the name which Tesla gives them, Superchargers. Superchargers are nothing special, it just means it’s a EV charging station, DC power provided, and branded Tesla. That’s also why we recently voted unanimously to deprecate Tesla socket tags, since there is no difference between the marketing term and the actual connector name.

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.

@GA_Kevin

EVgo (your first image) is likely the one wide-scale exception here. They name their dispensers cutesy human-like names which should probably use name=*. I couldn’t quite make it out on your photo but the name would be on that black colored label on the top of the screen I believe (as well as in their app.)

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.

@GA_Kevin

This was not in scope for this effort. Though it’s interesting that the hotel one you found was without a ref:supercharge_info or tags like website that were part of the import. It probably just caught tags like frequency and motorcar if I had to guess.

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.

@GA_Kevin

I agree, this is actually a much larger issue in the US than just Tesla, so many EV dispensers are tagged as charging stations, akin to tagging every gas pump as a gas station.

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!

[GA_Kevin]

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!

[TheNightRider]

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.

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!

[Rovastar]

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

Not showing name and showing brand of amenity=charging_station

[Minh_Nguyen (Minh Nguyễn)]

@GA_Kevin

@TheNightRider

iD now complains about nonstandard tags: operator=Tesla, Inc. is suggested to be updated to operator=Tesla. We know the name of the company is Tesla, Inc., so what’s going on with iD and how can this be fixed if Tesla, Inc. is the correct value? JOSM doesn’t show me this error (or maybe I just don’t know where to look).

iD and a few other editors use the Name Suggestion Index (NSI). That’s where it’s complaining from. It may be as simple as updating that tag on the second pass if NSI states something different. It was an effort to have different values for brand, operator, and network but maybe that’s… uh… unique? Yeah, let’s go with that!

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.

@woodpeck

I always thought the whole community, including the US, was largely in agreement that addr:* tags are for mail delivery and not for describing a location. If the US community is planning to deviate from that and use addr:* more liberally, maybe it would be a good idea to discuss this in a wider circle.

As others have explained, mail delivery is a useful way to describe the tagging scheme to beginners but has never quite been the raison d’être of address tagging everywhere. If we had somehow reached consensus that addr:*=* is always for mail delivery, then we were wrong. post:*=* is the tagging scheme that definitively corresponds to postal delivery points. That’s why it’s almost exclusive to amenity=letter_box.

In the real world, every country has not only its own address format but also its own notion about what an address can refer to. In the U.S., an address can refer to a parcel, street corner, dock, building, unit, door, gate, P.O. box, mailbox, or mail slot, depending on the relevant addressing authority. The USPS is not an addressing authority – they are not responsible for assigning addresses. That is the responsibility of local planning departments or in some cases private entities. The USPS does aggregate the local assignments, applying their own canonicalization rules for automatic processing (read: abbreviations).

Local entities assign addresses for a variety of purposes other than mail delivery, most commonly for identifying parcels. That’s why most building imports source addresses by joining the buildings to parcel datasets. In some rural areas, addresses are mainly for routing emergency services. In other areas, the standard addressing scheme is a glorified local coordinate system. Ordinary people understand these as “addresses” and we would do well to go along with it rather than aspire to a nonexistent standard.

It’s customary for lots of things that don’t receive mail directly to still have a street address and even a ZIP code. Here in San José, every street cabinet has an address assigned by the city planning department and posted by the maintainer. The following photo shows an AT&T cabinet located at 10 East Taylor Street. There is no building or parcel by this number. AT&T uses the address to pinpoint the maintenance crew’s destination, but in principle anyone could use it for… something.

The city also assigned 971 Great America Parkway to this railroad right of way that crosses Gold Street Connector. (Great America Parkway is in the neighborhood but not quite nearby.) I looked for a mailbox but found a large address sign instead. Union Pacific Railroad uses this address to direct their maintenance crews and probably also in official filings.

The USPS only has responsibility over the ZIP code, which originally referred to a delivery route but in practice is used for much more.^[1] Even when mapping buildings, 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.

At least we can all agree to never model addresses as associatedStreet relations, right?

@TheNightRider

Putting the onus on a data consumer to construct a URL from some bits is very problematic because how will they know how to assemble the bits? A complete “no assembly required” URL is straightforward and eliminates any assembly difficulty. In addition, if someone has the URL, they can deconstruct it for whatever bits they want.

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.

---

1. Some post offices additionally allow you to pair a street address with a P.O. box number, which of course would be under their purview too. ↩︎