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.
3 Likes
Thanks @RobJN, fantastic work on this! Your dedication and professionalism is shining here!