That literally doesn’t make any sense at all, you are conflating “NACS” the concept of the Tesla defined plug used by third parties, with the value that OSM uses for it, and that isn’t even NACS, it is nacs.
Tesla plugs are NACS plugs in North America. They standardized into SAE J3400. When not tagging, NACS is an acronym so capitalized. When in the socket tag it is lowercase.
1 Like
The answer again is that OSM didn’t have a, even de facto, standardized value for NACS plugs till essentially a moment ago, it is extremely unlikely that there is any consumer of a value that didn’t exist.
On the other hand the corresponding tags for the same connectors in use at Tesla SCs have been around for a longish time, a decade to be exact, and further there is an order of magnitude more of them. Replacing those tags with a currently still undocumented value without giving at least some notice because you are for whatever reason desperately unhappy with the current state of affairs would seem to be a tad bit unwise.
-
socket:nacshas a couple hundred uses. -
It is documented on the socket wiki page.
-
you still have not given an example of a single data consumer. I will assume this issue is all imaginary until then. I prefer a better, more accurate map than satisfying an imagination and holding onto the past at the expense of the future.The notice to these imaginary data consumers is there, in OSM and outside of it. If those ghosts don’t want to fix their data pipeline then that’s their problem, and OSM should not be held back by them.
-
Tesla is a brand not a connector
As an added bonus here is my non-Tesla car charging at a non-Tesla station using a non-Tesla adapter. Tesla was not involved at all because NACS is the standard the socket uses, Tesla is just a brand:
socket:tesla_supercharger has 2426 uses.
That documentation was added 2025-03-21 in this changeset, i.e. 11 weeks ago.
I don’t think this is part of the issue here.
I believe you have a good case, but straying into weak arguments doesn’t help.
My argument is OSM should be an accurate map of the world. There could be a million uses of an incorrect tree, that doesn’t mean it needs to stay.
My main point was that the concern was about data consumers. They’re imaginary. I have yet to see one appear. We are wasting energy debating to make OSM less accurate for a data consumer that doesn’t exist, and that’s a very “it’s how it’s always been done” take which when those start winning out is when projects die.
I fully agree.
And the counterargument was that the tag is very old and in common use, so there are bound to be data consumers which would work with the old tagging, but not with the new one.
I don’t think so? The main issue from what I can tell is that the old tagging isn’t as intuitive as it could be, hence the new tagging. But the information conveyed is basically the same, since the Tesla charger became the NACS charger.
The question then becomes, how much Backward compatibility - Wikipedia we are willing to provide.
As I told Simon, they are a poor data consumer if they don’t support a way to display NACS. I have no sympathy for those ghosts (again, no one can say a single use, much less one that rises to a point we should not update OSM ASAP). I’d also like to ask these ghosts how they handle stations like I shared in my image but that’s not related to the proposal and editing of tags.
I have a saved JOSM session with all these in the US switched to nacs and ready to go. I see no reason beyond entertaining imaginations here why I shouldn’t update the map to be the most accurate and in accordance with our wiki and industry standards.
As far as backward compatibility, data consumers use OSM because it constantly updates and isn’t tied to a slow versioning cycle, not despite it.
I’m sure you are aware of Automated edits - OpenStreetMap Wiki
Yet the only reason why users can always update the map is because it has a certain structure they can rely on. And part of the structure are the tag names - however badly they may be chosen.
Look at it like this: If your update was applied and such consumer were to update the map data, they’d be shown no charging stations at all!
You’d think that charging stations are of interest while in a car, so an infotainment system might make use of it. Afaik, it’s rather difficult to update the software, but the map can be updated easier. This is not a specific instance, but I think it at least gives grounds to believe that such consumer exists.
Of course, all of this doesn’t prevent new stations from receiving the new tagging.
Who? Please, someone name these ghosts. If we have to prove a negative (no one anywhere uses a tag in an undocumented way) no tag should ever get updated.
I truly believe everyone here has the best interest in mind, apologies if I come across combative. To me, this isn’t a blunder we should just accept (like the fact none of these are sockets, they’re connectors) it’s an actively incorrect tag that belongs in brand and only is around because Tesla was the first to deploy a major network with a proprietary connector. Times have changed, OSM should too, and sooner is better than later to me if we know what’s wrong and how to correct it.
Rob did a great job on this proposal and I think we all support it. It’s just a matter of how fast to implement the community-approved change. If there’s no data consumer we can name, why not asap?
From the proposal:
Tesla vehicles built prior to 2021 are incompatible with the CCS protocol and require a retrofit to become compatible with CCS. However, the Tesla Supercharger network remains backward compatible with the prior proprietary CAN bus standard (i.e. Tesla chargers can use both the CAN bus and CCS protocol depending on what vehicle is connected).
To me, that sounds like it might be reasonable to dual tag Tesla charging stations (and I mean the brand) with both.
Non-Tesla chargers are incompatible with older Tesla vehicles, so those chargers shouldn’t be shown anyway.
If newer software expects the old key, then they can at least see the Tesla stations. At that point I would just say ask them to update the software or live with the limitations. But it’s not unusable.
In this specific instance, could you live with that?
This is the downside to Tesla having first-mover advantage. They made a decision that turned out not to be the right one down the road that requires a retrofit to work with existing standards. I suspect Nissan Leaf owners with their CHAdeMO port will soon face the same fate. I am importing new US DC Fast Chargers each week and every week seems to have less and less CHAdeMO support.
That said, this isnt something to do with the supercharger, this has everything to do with the vehicle. That information would belong on the vehicles entry (like in Wikidata) but the station itself can charge it post-retrofit. The onus is on the owner to either get a retrofit or know that they can only use superchargers (in North America this can be found by filtering amenity=charging_station by nodes or ways with brand:wikidata=Q17089620 per the Name Suggestion Index (NSI)) Maybe a case can be made for an access conditional, but that is not in scope of this proposal.
Similarly, I have been having discussions on importing supercharge.info’s database into OSM and they have been cooperative, and are allowing us to use their data. My most recent “OSMUS State of Charge” goes over that. Another challenge there is not all superchargers are open to all EVs with a NACS → CCS adapter. The automaker must be a “Tesla partner” to use the supercharger network sites at V3 and V4 superchargers. So far, when looking at the data, I have been converting this to access=no + access:conditional=yes @ tesla_vehicles when a station is Tesla-only. Again, this is something tangently related but not related to this proposal. If we want to discuss it I would be happy to. I have several US-based projects going right now to clean up and update and add EV infrastructure to the US. It is a mess and every data consumer Ive seen or talked with have said the same.
For what it’s worth, all the data consumers I have seen support NACS tagging. Supercharge.info and OpenChargeMap to name 2 I’ve dove into the data of.
1 Like
Ok, lots of messages since I was last online. I think we need to step back a moment. Some key points:
- Nobody is doing this with the intent of breaking existing data consumers processes. We want good quality data in OSM, have identified that a tag change will make this easier, have followed all the steps related to RfCs and I have tried to share this as widely as I can (e.g. I submitted it to WeeklyOSM). There has also been plenty of time - this has not been rushed through.
- The next stage in the RfC is to actually see if this change get’s approval. Hopefully it will, but it may not, in which case we are making noise about something that won’t happen!
- If it does get approved, it doesn’t mean an instant change. As has been pointed out nobody should be making bulk automated edits without first following the relevant processes (see Automated edits).
- Deprecating the tag means different things in different regions of the world. In many places it would mean switching out one established tag for another long established tag. But in north America it does mean a relatively new tag (one that was probably inevitable anyway since NACS is now being used at non-tesla sites). Local communities should therefore act appropriately. A slightly longer gap between an “approval” vote, and implementing tagging changes could be one option.
- We have a list of some data consumers on taginfo (here). I will notify them all, either via a project address or via an individual that I know is well connected to each project.
If there is anything else you think I should be doing, please let me know. I want this to work and I want this to work well.
5 Likes
Thanks @RobJN, fantastic work on this! Your dedication and professionalism is shining here!
Relax @GA_Kevin
I have not been very active on OSM for a few years but things do move slowly move along (glacial speeds at times).
Getting to changing tag things properly can take forever. Sometimes (or the cynic of the process in me what say often) the paperwork and red tape to get thing done gets in the way. There can to be too much to take in. I looked a few years ago at the charging_point tag and it was a complete mess and not fit for any usefulness. I gave up even trying to get it sorted as it was too much work and get the majority to agree on anything here is like herding cats. They can mostly agree something is poorly implemented but cannot agree on the solution.
But things got better, there is still a bunch wrong with that tag that can be improved but it is at much better base than a few years ago.
Things like this socket were obviously wrong (now a more official name is recognised) and the worst of it was the ccs tag for this socket:tesla_supercharger_ccs monstrosity which hopefully this will address. Realistically these could have been changed by hand in the tags in the background and few would object but to change it properly to need to go this long process @RobJN is going through.
Progress does happen even a slow speeds we even have swimming pool tags I’ve noticed in one place now and that only took 15 years! The NSI has done wonders since it was introduced. It’s less of the wild west than it used to be.
And finally regrading this proposal it looks good the only real question for me was around J3400 and nacs naming. If it was just north America markets I can see it making complete sense it is unclear in the other markets Japan, South Korea (and there are some in Taiwan and Hong Kong too) how they refer to them if they get mainstream/government backed adaptation (Japan and South Korea will move to a new standard soon as there are outdated) what will they call in. But happy with nacs as it is the most common term and noone like or really calls it J3400
Oh, I’m aware! I’ve had successful and not successful formal proposals before! But yes, this proposal is good. Great, even. I don’t see this not passing. I personally vote for socket:nacs since that is how connectors are labelled in the real-world in the United States (such as my photo above), and we tend to not tag as the standard, but if someone from another country that uses NACS has more on-the-ground knowledge, I am all ears! I think the China and rest of the world switch will be much easier as a 1-to-1 swap.
Thanks all. The voting stage is now open! Please add your vote to Proposal:Deprecate socket:tesla supercharger and socket:tesla destination - OpenStreetMap Wiki
2 Likes
I have contacted Pieter at MapComplete and opened tickets on the issue trackers for Vespucci and OSMAnd. It could result in some voting against the change as it will cause work for them but hopefully not.
Anyone know how best to contact Flosm POI and the JOSM team?
I have also submitted an article for the upcoming WeeklyOSM.
I am planning on adding it to my weekly “OSMUS State of Charge” on Sunday!
1 Like