Bulk import of Tesla Superchargers in the United States

[woodpeck (Frederik Ramm)]

@GA_Kevin

I think @MikeN covered this quite well, it is not a complete address in the US without a ZIP code. That may be regional but this is the OSM US forum and this edit was solely based in the US.

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.

I know that some people use object:* to describe that “this thing is near this address but it is not the thing that has the address” (e.g. a vending machine that sits in front of house #123 on ABC street would sometimes be tagged object:housenumber=123 and object:street=ABC street but never receive addr:* tags).

[TheNightRider]

@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. I

Every Supercharger location gets equipment shipped to the site, and that requires an address. In the US that address requires a ZIP Code, even if it’s UPS, FedEx, or some trucking company. It won’t be the US Postal Service because it’s above their weight limit. You can see this on the shipping label of the equipment.

Recent example from the Lakewood, CO, USA Supercharger site that just went live. Here’s the outside of one of the cabinets, complete with ZIP Code:

[ZeLonewolf (Brian M Sperlongano)]

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

This is false for the United States.

The addr:* tags are definitely used for street addresses rather than postal addresses.

These are usually the same, except that there are places in the US where the Postal Service does not deliver. In those locations, residents must obtain a numbered Post Office Box to receive their mail. I assure you that the addr: tagging on those people’s houses are not “P.O. Box 1234”. This occurs most often in rural, remote, or private residential locations.

One example of this is Utqiaġvik, Alaska (formerly known as Barrow). There is no residential mail delivery in the entire city of Utqiaġvik; all mail must be retrieved at the post office, where it is addressed by P.O. Box.

However, there are streets with names and houses with numbers, which are used to describe the location. Here’s an example:

Way: ‪722 Nachik Street‬ (‪500271964‬)

Furthermore, postal addressing requires an apartment or unit number when you have one building with multiple addresses that each receive mail. For example, there are buildings in New York City with hundreds or even a thousand or more apartments in them. Yet, it’s the building that is represented by addr: tagging, not each individual apartment where mail is delivered.

I would be surprised to learn that the rest of the world does this differently.

[GA_Kevin]

RE: ZIP Codes

All the station data I can see from Tesla, AFDC from the US Department of Energy, Supercharge.info on a local Tesla Supercharger has the full address including ZIP. Likewise, a nearby station’s permit drawing shows the full address including ZIP. So in addition to what others are saying and the fact that people navigate to these all the time and expect a full address, I think it is fair to include the ZIP code on these stations despite their inability to receive mail.

[Spatialia (Nick Santos)]

@SimonPoole

isn’t appaudable hard work

Coming into a thread and berating people who are actively soliciting feedback on how to do the work better certainly isn’t applaudable.

If you can’t participate to the level of making concrete suggestions for improvement, then I’d recommend staying out of the thread entirely. Coming in and making flippant remarks about the individuals doing hard work to improve data, and also slighting the broader community is harmful to everyone.

@GA_Kevin is clearly open to and engaged in making this import better, and I appreciate and see the work here.

[SimonPoole]

In case you didn’t notice, @GA_Kevin broke existing good data very publicily in front of a global audience, making if more difficult all over the world to argue for the use of OSM. That is when it stops being just a local matter.

Further I would take issue with describing importing trash as hard work, that has simply been the go to excuse of the US community since the very beginning.

[GA_Kevin]

Hi Simon, breaking data is not the intention. Can you please link to where you see this data getting worse? If the concern is “replace geometry”, the largest offenders have already been placed back in their correct spot. The remaining ones we’re looking at less than 100 meter difference. It’s ongoing. Also, you mention worldwide, you can check my HDYC if you like, but ive only ever edited in the United States (with 1 exception of helping a small town in Kazakhstan when I saw the call for such in the OSM world discord - where I edited one warehouse).

[clay_c (Clay Smalley)]

Hi all, we’ve gotten a few flags on this thread. We’d like to remind everyone that the OSM US Code of Conduct applies to this subforum.

While there’s nothing that explicitly violates the CoC, please keep in mind the Encouraged Behaviors while discussing issues here:

• Be welcoming. OpenStreetMap US strives to be a community that welcomes and supports people of all backgrounds and identities. Some examples of behavior that contribute to creating a positive environment include:
  • The use of welcoming and inclusive language;
  • Respect for differing viewpoints and experiences;
  • Empathy towards other community members.
• Be considerate and patient. Actively seek to acknowledge, respect, and understand fellow community members. Our community depends on the work of each other to maintain and strengthen the health and integrity of OpenStreetMap. Any decision you make may affect others, and those consequences should be taken into account. While critique is a natural and important part of our culture, good critiques are kind, respectful, clear, and constructive.
• Assume good faith. It is surprisingly easy to misunderstand each other, be it online or in person; particularly in such a culturally and linguistically diverse setting as OpenStreetMap US. Misunderstandings can easily arise when we are in a rush, or otherwise distracted. Please ask clarifying questions before assuming that a communication was inappropriate.
• Be respectful. Enthusiastic discussions are part of the lifeblood of a successful project but can also lead to disagreements. We should strive to keep our discussions and disagreements appropriate. Members of the OpenStreetMap US community should be respectful when dealing with others, within and outside of the global OpenStreetMap community. We note, however, that non-OpenStreetMap US spaces are not part of this Code of Conduct.
• When we disagree, try to understand why. Disagreements, both social and technical, happen easily and often. It is important that we seek to understand each other and work to resolve disagreements and differing views constructively. When someone contradicts your own perceptions, try to understand where the other person is coming from. Try to ask questions that will serve to clarify, rather than to escalate, an issue.

[TheNightRider]

@GA_Kevin

Most of the time, a source goes on the changeset though not so much a delimited list on an element. This may be different in your use though!

It probably makes sense to put source URLs in the changeset comments, because we don’t put “Aerial imagery” in a tag, and it is one type of source. So why is there a source key if sources are always supposed to be in the changeset comments?
Key:source - OpenStreetMap Wiki shows this is not set in stone. It would be handy if this got decided, but there’s probably years of discussion about the issue.

We can be consistent, though! However, right now we are still inconsistent because there’s the tag:
source=https://supercharge.info

So, I suggest that be put in the changeset comments as well, but as a full URL like https://supercharge.info/map?siteID=5423 @Rovastar,what do you think?

[TheNightRider]

After @Rovastar came up with the nice map-less URLs, I did some investigation on the Tesla list of chargers (both Supercharger and Destination Charger) and they do have a list:
https://www.tesla.com/findus/list

There were some new sites that weren’t on it, which is what I was getting at, but it looks like they just hadn’t yet updated the list.

The great thing is the list has short URLs (that don’t end up at a messy URL and a “competing” map at the top) for BOTH Superchargers and Destination Chargers. Example at the location where there’s both a Supercharger and a Destination Charger:
Supercharger, Denver, CO - 12075 East 45th Avenue
Destination Charger, Denver, CO - 12075 East 45th Avenue

BTW, @GA_Kevin that particular Destination Charger got touched by the 6/22 bulk import from supercharge.info, even though it’s not a Supercharger. The tag:
frequency=0
got added, but that means DC. Since this is AC and in the US it’s 60 Hz, I just changed that to:
frequency=60

There might be more! Are you planning to find them since you’ve got a script working already?

One thing I am not sure about is this: can non-Teslas with a NACS port or adapter charge at a Destination Charger?

[TheNightRider]

@GA_Kevin

that’ll probably be one of my cleanup activities once imports are set from the AFDC to remove name in favor of brand with the few exceptions where it’s signed.

So if name is removed, then there will be nothing on the map except a charging symbol. That might not be good. In several Asian countries they actually do have a big sign that says “TESLA”. Here’s the new Supercharger in Gapyeong, South Korea - Gapyeong Rest Area (Seoul):

In the US there’s not a separate sign (maybe someone has seen one, but for sure it’s not the norm), but every post has “TESLA” at the top, so you could consider that a sign. It doesn’t say “TESLA Supercharger”, so then what will be the effect on map data consumption if both Superchargers and Destination Chargers have the same name=TESLA ?

[ZeLonewolf (Brian M Sperlongano)]

@TheNightRider

So if name is removed, then there will be nothing on the map except a charging symbol.

Please don’t tag for a renderer. Different maps will display things different ways. It would be better to say “how are similar types of POIs tagged?”

[TheNightRider]

Right, I know about that, but we do have to think about what will happen when we tag things a certain way. In the beginning, what did the renderer do? No doubt not as much as now and over time new symbols have appeared. So we can’t not think about this issue.

I was just looking at some Supercharger stations in the UK, and many have a name that might not be on any sign. Examples: London-Westfield Supercharger, London-Park Royal Supercharger, Medway Eastbound Supercharger. There are many examples in the US as well.

So the question is, should there be no name for Superchargers or any chargers, for that matter, and only have the brand or network tags? If a renderer would deal with that for someone looking for a particular charging brand, it should be fine, right?

[GA_Kevin]

@TheNightRider

So why is there a source key if sources are always supposed to be in the changeset comments?

I think it’s more used as a subkey such as opening_hours:source=signed. But don’t quote me on that. For this case, on the changeset makes the most sense.

@TheNightRider

So, I suggest that be put in the changeset comments as well, but as a full URL like https://supercharge.info/map?siteID=5423

In an effort to be flexible I think allowing a data consumer to construct this URL themselves with OSM data would be best. We already give ref:supercharge_info which is that last part siteID. If supercharge ever changes their url you’d then just have to change one line or so in each data consumer instead of trying to keep OSM up to date on the latest URL schema.

@TheNightRider

There were some new sites that weren’t on it, which is what I was getting at, but it looks like they just hadn’t yet updated the list.

I would roll my eyes and say “ugh… Tesla” but honestly all brands do this, even in the AFDC so much there’s a term for it, a “sleeper site” where it’s been spotted in a survey but not in a database.

@TheNightRider

I just changed that to:
frequency=60

Great, perfect! Thank you!

@TheNightRider

There might be more! Are you planning to find them since you’ve got a script working already?

Its a bit of a chicken-and-egg problem but the short answer is yes!

@TheNightRider

can non-Teslas with a NACS port or adapter charge at a Destination Charger?

I would assume so, they are to my knowledge no different than any other Level 2 EVSE and you don’t use the Tesla app for destination chargers so I’d say yes until proven otherwise.

@TheNightRider

So if name is removed, then there will be nothing on the map except a charging symbol.

I really, really want to encourage people to use brand where there is no name. Adding name because a renderer expects one is not great.

@TheNightRider

It doesn’t say “TESLA Supercharger”

You are correct! No where is it signed Supercharger in most places (dare I say all?) It is simply a marketing term to mean a Tesla branded, DC Fast Charger.

@TheNightRider

so then what will be the effect on map data consumption if both Superchargers and Destination Chargers have the same name=TESLA

Both should have brand=Tesla in my opinion, with the distinguishing factor being frequency (60 vs 0), socket:nacs:output (higher with DC), and access (most destination chargers are more restrictive than Superchargers.)

[TheNightRider]

@GA_Kevin

@TheNightRider

So, I suggest that be put in the changeset comments as well, but as a full URL like https://supercharge.info/map?siteID=5423

In an effort to be flexible I think allowing a data consumer to construct this URL themselves with OSM data would be best. We already give ref:supercharge_info which is that last part siteID. If supercharge ever changes their url you’d then just have to change one line or so in each data consumer instead of trying to keep OSM up to date on the latest URL schema.

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.

[TheNightRider]

@GA_Kevin

I really, really want to encourage people to use brand where there is no name. Adding name because a renderer expects one is not great.

That would be fine if there is no name, but as discussed above, there is indeed a name. Supercharger posts all have “TESLA” on them, except for maybe some that Tesla has sold to some company for fleet use. I’ve also read they might sell some (or already have sold) to companies that want to put their own brand on them. I know zero about that at this point.

Other DCFC brands have their brand names on their posts - EVgo, Electrify America, Freewire:

Tesla L2 chargers have no name, but plenty of others do - EVgo, ChargePoint, Schneider Electric’s EVlink, blink:

So, if we want to get rid of the name=“whatever” tag and use the brand, the default OSM renderer (Carto) will only show an icon, which makes the map far less useful. You can’t just look anymore and see even what brand a charger is; you have to click on every icon. That would be a step backwards. If the community agrees to dynamite the use of name tags for EV chargers, Carto needs to be updated BEFORE all the name tags are dynamited.

[TheNightRider]

I found a couple more interesting bugs that happened with the 6/22 bulk import from supercharge.info:

1. The bulk import only touched nodes, but not ways, so the Conifer, CO Supercharger wasn’t updated. I had actually added Conifer back in 2023 as a way before I knew it was better to add nodes. I was in the editor (iD) and, looking closely, I then saw there was a new node on top of the way, and it’s not named. That came in from the bulk import. I’ve left the situation “as is” so you can see the issue. However, it’s not being rendered by Carto in the default layer at https://www.openstreetmap.org. You have to go into edit mode with iD (or use JOSM) to see it.

The original way:

The new node superimposed on the way:

[TheNightRider]

Interesting bug 2:

2. The bulk import did not check to see if anything tagged with name=“Tesla Supercharger” was actually a Supercharger. Here’s how I found it. I was looking for a typo I had made in a few Supercharger station notes, and couldn’t download the entire US, so I picked metro Denver, for which I’ve added a lot of stations and touched them all. I used the Overpass API to ONLY download elements with name=“Tesla Supercharger”:

I got everything I expected, except a suspect new one:

Grabbed some imagery:

Zoom in. Hmm, there’s no Supercharger there.

Zoom in some more. Hey, that’s a hotel!

Found the garbage entry point. Someone mistakenly tagged a Destination Charger as a Supercharger back in 2019:

And, of course, as the ancient saying in computer science goes:
Garbage In, Garbage Out!

Tesla shows this as a Destination Charger:

So then I retagged it, leaving only the tags I was sure about:

Then I realized I wasn’t sure about the fee, so I deleted it:

Then I called the hotel and they confirmed there’s no fee. It’s not networked:

Whew!
p.s. Let’s find mis-tagged stuff like this, too.

[GA_Kevin]

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

@TheNightRider

A complete “no assembly required” URL is straightforward and eliminates any assembly difficulty.

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

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.

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

Please don’t tag for the renderer, we have Issues in with Carto to get the brand displayed but OSM data should lead renderers not renderers lead OSM data! And Carto is not the only renderer out there! Heck, it’s not even my favorite!

@TheNightRider

The bulk import only touched nodes, but not ways

Yes, working on the write up for the cleanup on this. I have an Overpass query with these adjacent nodes with ref:supercharge_info and stations without (ways). Will likely pick that up after the US holiday this weekend.

@TheNightRider

The bulk import did not check to see if anything tagged with name=“Tesla Supercharger” was actually a Supercharger.

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. Thanks for updating this one and for going above and beyond by calling the hotel!! Truly admirable work there!!

@TheNightRider

p.s. Let’s find mis-tagged stuff like this, too.

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. You can substitute the relation ID in this Overpass query to find these ugly ducklings, this one is for Massachusetts since SOTM US was there last month and I wanted to show the issue:

rel(61315);map_to_area->.state;
nwr[amenity=charging_station](area.state)->.allStations;
foreach.allStations->.station(
  nwr(around.station:100)(if:t["operator"]==station.u(t["operator"])||t["name"]==station.u(t["name"])||t["brand"]==station.u(t["brand"]))
  [amenity=charging_station]->.new;
 ((.new; - .station;);.adjacent;)->.adjacent;);
.adjacent out;

Also regarding general cleanup of EVs in the US with both SC.info and AFDC, Ive created a MapRoulette challenge to ask people to double check things:

MapRoulette