This is a continuation of a discussion started in a PM. Here is what has been discussed up until now:
1 Like
One way to get a list is to use Overpass Turbo frontend for the Overpass API. This link should lead you to a query returning all superchargers mapped in OSM: http://overpass-turbo.eu/s/1N62. After zooming in on an area, you can click “run” in the top left and then “export” for some data format options. The Overpass API is extremely powerful - this query is only a small taste of what it can do. I highly recommend taking a look at this page, if you’re interested: Overpass API - OpenStreetMap Wiki
In the OSM world, mapping charging stations as ways is considered superior in terms of detail, with nodes really only being used to reduce effort or if sufficiently detailed sources are not available. Currently, most stations (~97%) are mapped as nodes, but in the future I expect many to be changed to ways. So it would probably be a good idea to find a way to handle both.
It is probably also worth noting that the IDs of OSM ways and nodes don’t always stay the same. In theory they should, but in practice the nodes and ways sometimes get deleted and re-added. The ID also changes when the charging station info is moved from a node to a way or vise versa.
Hi @jmarchon
Welcome to the forums.
Many of the editors here are familiar with OSM. I’ve personally been involved from back in 2007, heavily involved before but a more casual editor there now.
We will discuss amongst ourselves here to have a more open license.
Our general intention is people can use our data freely.
Never sure what the super strict rules of compatible to OSM licenses are nowadays,
What do you intend to do with our data on OSM? Importing them worldwide (imports can be tricky with duplicates already in OSM)? Just adding some to your local area? (I see you added some recently)
Personally I find the implementation of EV charging a right mess in OSM (multiple implementations of the same thing, misleading, outdated or outright wrong guides in the wiki last I looked, etc) and I haven’t the energy or inclination to start adding these on mass.
However if you want to do the heavy lifting of dealing with the OSM import mailing list and getting consensus in the community to potential use our data then feel free. I would genuinely welcome that, it would be great for OSM.
(Most useful I think for OSM would be to for matching OSM ID where we could import/update site information with the stall counts and power once as we keep on top of this really well.)
We have been adding OSM IDs (getting ways added is already earmarked but as you say not many of those about) but over the past few months. We could overpass API to get more info but I think we are adding them at a steady pace. For areas like Europe where OSM is more mature we have added many, US doesn’t have that many, and I expect near zero in China.
Thanks @jmarchon for posting this. Hope it leads to a robust discussion, and as both @Rovastar and I said, we’ll continue discussing our licensing approach internally.
My apologies, I wrongly assumed you weren’t familiar. Sorry for explaining things you already know.
I was hoping to use your data as a reference for manually adding stations to OSM. I already have other sources, but your data seems to be one of the most accurate. You also provide a convenient feed for additions/removals to the supercharger network. For now, I don’t intend to perform an import. Maybe sometime in the future once the guidelines/tags for mapping chargers on OSM have improved and settled.
Hello all, I have started a large undertaking to get the United States up-to-date on OpenStreetMap as far as EV charging stations go. I am focusing initially on DC Fast Chargers that are public use. Naturally, I saw supercharge.info as a great resource for Tesla Supercharger information.
As a testbed, I focused on my home state of Georgia, U.S.A, using the supercharge.info allSites endpoint, I then filtered down to just open Georgia locations. I then converted your values to OSM appropriate values. I notably changed your id column to correspond to ref:supercharge_info in OSM (using the principle of “any tag you like” to add this new tag).
This provides a useful field to link our databases, as id will equal ref:supercharge_info for not only missing stations but also any updates on either end to sync. In Georgia, I have compiled a csv of this to show OSM IDs alongside Supercharge.info IDs. It can be found here.
Exports like this may help update OSM links within Supercharge.info. I would be happy to convert into whatever you need to import the osm data as appropriate.
Hopefully this test-import was okay from your perspective. If not, I can revert the OSM changes but it seems we are fairly open on both sides to using the data. OSM uses the OdbL officially so any matching of that would enable the data sharing, but also just a notice from supercharge.info that you are okay with this use of your data would suffice as a “license exception”. I am not a lawyer and much more interested in the EV data than legal jargon.
If you are happy with this, I would love to import all of the United States into OSM and offer any exports you’d like to update your database as well.
I am also updating weekly from the AFDC and working on a few other sources and updating our wiki pages to make this process and any future mapping easier.
1 Like
Excellent job @GA_Kevin
It would be great to import our data into OSM. Happy for you to use that.
-
If there are already tesla supercharger stations in OSM that we don’t have an OSM ID for. What do you? Just add a duplicate? Or are you doing some comparison?
-
Sometimes charging stations in OSM are marked in ways not nodes. We currently don’t support this. I presume you will just add an additional node.
-
Are you planning to keep this updated when things change, like sites get removed, expanding sites or upgrading stalls say V2 to V4.
-
It doesn’t seem to have all in Georgia. For example, supercharge.info oh I see that was like tempclosed when you did the import. I would suggest adding in temp closed status sites (as we likely believe they are just down for maintenance or something) and all expanding status (expanding sites are open currently and have an expansion underway)
Other enhancements you can make for the import
a) You could add a link to the tesla page like
https://www.tesla.com/findus/location/supercharger/
b) sometimes there are multiple stall types on a site like supercharge.info
There are 4 types urban, V2, V3 and V4. urban is 72kW, V2 is generally 150kW, V3 is 250kW and V4 is generally 325kW in the US. we don’t state this in our data we just give the stall type and the maximum power for the site. It’s would be technically correct but not sure how you do it in OSM to break all these down rather than one large site that has the same power.
From our point of view it would be great to get them all in OSM and then we could import back in plugshare IDs if they are added to OSM and maybe even EFDB data at some point if we decide to use that.
Once you add them all please let us know and if you provide us with a csv of our siteID and the corresponding OSM node that would great and we can import them into our database, Win, win.
Slightly related. I updated many superchargers across Europe. Can I somehow myself update the links to osm on this website?
Hey @Rovastar!
Thanks for the go-ahead!
So for the GA example (and others going forward) I do not use your OSM ID field. What I did was I cleaned up the whole file to use OSM-compatible tags then loaded into a program called JOSM (JavaScript OpenStreetMap Editor) where there is a conflation tool. I basically told it if an imported station shares a brand or name with an existing OSM amenity=charging_station, and within X distance (I forget the exact value I used), notify me to conflate the supercharge.info into the existing OSM station (making a new version of that station rather than a new element). If none exist in OSM already, a new station is created as a node.
Is there a technical reason I may not understand that you don’t support this? On my example above with the IDs exported, it happened to only have nodes but it would export something like id is way/[idnumber] which means the url you’d use for supercharge_info is https://osm.org/[id]. This also works for the rare but documented times we use a multipologon relation to show disconnected geographically but associated charge points (stalls in Tesla lingo).
Ideally yes, much like I am doing each week with the Alternative Fuel Data Center with non-Tesla stations. My first task is to get everything imported though, then it can switch to keeping in sync, if that makes sense. I did add “planned” and “construction” stations in Georgia, using OSM “lifecycle prefixes” [I had to remove this link due to being a new member] which include gracefully decommissioning as well as construction tagging. Here is an example you marked as planning or permit in Thomasville, GA: [I had to remove this link due to being a new member]. Once that status changes you could then see on the OSM node history when different information changed by looking at the version history (right now it is just version 1 since I just imported it).
Ya know, I wondered why there was a couple missed myself when I went back a few days later, the Helen, GA one stood out as one to me. Good to know about the tempclosed status, that should absolutely be included. If we know for how long something will be closed we can use conditionals in OSM to show “this station is no access from X-X but open 24/7 otherwise”. It’s just a matter of how often we update and how much information (especially dates) anyone knows about the station. I’ll add that to my list to document on the ref:supercharge_info OSM wiki page I will now create now that we can move forward.
Are these standardized URLs? I wasn’t sure so I didn’t add them in my test import but if the URL is always that tesla link followed by another ID, that’s easy enough to add when I am in Excel updating the column names to OSM tags (or one quick python script away).
OSM does not distinguish between “type” (destination vs. supercharger) or “version” (V2-4) explicitly in a tag. This kind of granularity can either be in a description=* tag which is just a text box we can say something like description=20 V3 and 20 V4 Superchargers with Magic Dock behind Buc-ee's. However we also have a more standardized way to express this using semicolons. For that same Buc-ee’s station:
socket:nacs=40
socket:nacs:output=250;325
socket:type1_combo=20
socket:type1_combo:output=325
(we can also add amps and volts if they are known per-version, in addition to the “output” in kW)
As you see, the overall station is more concerned about the maximum that can be provided by any single stall, however…
This is also where I’ll mention in OSM we have another element called man_made=charge_point which is each individual dispenser (stall in Tesla lingo). While each station only has one station node, way, or relation; it can have theoretically infinite man_made=charge_points nearby which can be queried (i.e. how many charge points are nearby to this amenity=charging_station element). Then specific data can be added per port, including status if displaying this somewhere as a data consumer, but also within OSM the exact stall type information or parking instruction.
I also created ref:plugshare=* based on your data, I think it would be useful to have as so many people in the US use plugshare and their URL scheme uses their IDs. It is proprietary and commercial which is not my favorite thing to support but I see the benefit. Maybe if we can get all these open-source sources together we can make something better than PlugShare. But the short answer is yes, we now have ref:plugshare which we can use across both databases and that can be extended to any reference value (the top level ref=* tends to be the reference number of the station itself not a value from a database).
For sure, that export took maybe 5 minutes with 1 overpass query and a quick python script to convert the geojson to csv. Simple enough to send to you or I can also just share the script to query osm if you’re ever curious to do so on-demand.
Ok cool. I know (or knew not used it for years) JOSM for when I did large changes in OSM. It seems a sensible approach.
The way thing was that it wasn’t coded that way for use and the dev who did it isn’t around much now, ideally we would have a way in our system but that isn’t happening anytime soon. nodes it is. It seems sensible for you to update OSM if a relevant way exists.
I wouldn’t add any planned or permitted sites to OSM these can often fall through or more locations wildly. Construction should be a more accurate but even then mistakes get made like it turns out to be another CPO.
For temp closed we don’t really know any timescales it could be a fire or some other damage or the site host has closed the area for a refurbishment and at some point it will open . We just know the station still exists and we think it intends to come back.
I looked up again the multiple power at a charging station as I thought OSM did implement this poorly (like most of it in OSM as I ranted about before in this thread) it is such a shame as many large sites from a CPO or charging network have multiple charging power and still no way of showing this and I noticed a new proposal for EV charging in the wiki and it was by you! Bravo Kevin. Courageous to dealing with the OSM bureaucracy. I’ll add my thoughts to the proposal over there. Maybe there can be progress on this I think the socket type was one of my massive bugbears as it is tesla_supercharger as standard in the US and some abomination for the Tesla European CCS2 socket even though they are the same. (yes socket and not plug is technically correct but Noone uses that language in the real world)
But I can chat on osm wiki about that as someone is spearheading that now!
Just to note our data although we thing great some of the location coordinates may be a little off.it should be good enough but could be the wrong side of the parking area. Is there a way to let us know if the OSM existing ones where they have them are different by a reasonable distance. It would be good to for us to know and we can readjust if needed.
I see using your OSM tags as being imported to our dataset. And It will be much easier to keep thing updated once (or even imported) we have a good base.
Are you thinking about the a world import to some next?
I don’t really understand JOSM most days but I do for imports and edits like this! But for day-to-day editing I still like iD or MapwithAI (Rapid). Talk about OSM bureaucracy with JOSM! I wont touch that topic with a 10ft pole.
Ah, my mistake, I was thinking it was just a link to OSM not more on the backend.
I will make a note of this on the import wiki, confidence should probably be quite high before adding to OSM in my opinion.
Thanks for that – OSM should just state the same as if it were open and if/when a data consumer wants to use the data they can overlay temp statuses like this.
Just for your knowledge if you stumbled upon the site relation proposal I made recently I am dropping that after OSM community pushback pretty much unilaterally. However, the idea still applies that we can query charge points nearby the charging station to get the fuller picture of the station without explicit (and complicated to map) relations. Simple enough for a casual mapper and only involves a slightly more complex overpass api call on the data consumer side.
The socket value change from socket:tesla_supercharger to socket:nacs (in the US) and other standard connectors is rather imminent. There is a formal proposal about to go to a vote but I have already updated the soocket page with essentially 0 pushback to include a warning not to use the tag. I have a query ready to go to update all superchargers in the US to socket:nacs once approved. Especially with Tesla standardizing the connector and non-Tesla stations starting to support it, it just makes sense.
That is certainly queryable. It’s just a question of which is the source of truth on either end. This happens in the AFDC imports too, the Department of Energy will state it’s on the wrong side of the parking lot, etc. but I have erred on trusting OSM contributors surveys for the precise point vs constantly adjusting / averaging for every new source I import. It should be easy enough too to use something like MapRoulette to ask the community to use satellite imagery to place the point in the center of the station. But that needs the point to begin with so importing is first!
I can certainly reach out to some of the worldwide EV mappers to see if they would be interested, but my challenge is large enough with the US right now. Especially when adding in updating / syncing manually until imports are done and I can work on automating things (especially since I am trying to do all charging stations, not just Tesla). It will be a lot easier to suggest an automated edit bot if everything is imported and looking good first. If that day ever comes, I could look to international.
Cool. I look forward to it.
I’m surprised you don’t get push back for the sockets (I noticed after you posted the socket page had changed after I last looked at it) and they will call it SAE J3400 or something.
There are some proprietary Tesla connectors/sockets too. The modified type2 for the multi cable stalls in many parts of the world with the V2 stalls/charging points.
(Just as aside now I have read your OSM proposal I probably would not have approved it too. Some good ideas but they were mostly covered in other ways. There is still a lot wrong with the charging station tag but I think amendments to it rather than changing how to is functions. And there are lot of charging station types around the world the US is relatively simple compared to some having more international viewpoints would make.)
If you could start doing imports to OSM that would be great. There are more things that we could add. Total site power (that I can work out), multiple stall power using the ugly ; notation OSM has, linking them up with AFDB, amperage?, voltage?, station opening times, opening date, etc
There might be a few anomalies here and there but we can cross that bridge when we come to it.
I know some of the AFDB stall counts are off and there are one or two locations where our data might throw up something (there is one station in Las Vegas that we call 2 stations as they are far apart but really it should be 1 in OSM with a multiploygon, (and tesla and I expect AFDB call it 1 station)
Thanks for your work on this.
@ffaebi We are OK for editors in general for the moment. For the OSM side of things I know a lot of links are missing still. I’m going to see how @GA_Kevin goes with his project and hopefully get a lot of our data into OSM and update our site with a lot of OSM links.
Yeah, the official spec is J3400 I think, but OSM tags use the more familiar “North American Charging System” (NACS) to mean the AC/DC plug formerly Tesla-exclusive. Any new stations I add will be using socket:nacs:*=* instead of the deprecated supercharger tag.
For the proprietary connectors I used the following when importing the supercharge.info data in the US:
| Type | Supercharge.info allSites | OSM tagging |
|---|---|---|
| Tesla-only stations | otherEVs (False) |
access=no + access:conditional=yes @ tesla_vehicles |
| Tesla partner site | otherEVs (True) |
access=yes |
The wrinkle here is “Tesla partner site” is not exactly synonymous with “Any EV with a CCS → NACS adapter” since some automakers still can’t charge there. I believe this will not be an issue for long but for the time being there’s not a great way to say that. Perhaps instead it should be access:conditional=yes @ tesla_partners? I just thought of that, haven’t stress tested it.
Total site power should probably go on the amenity=charging_station node as much as I don’t like that. There may be non-EV uses where someone is querying OSM data for power draws or something which the combined total would be useful. The amperage and voltage are useful on the man_made=charge_point(s) as that is where they are applied.
I am perfectly happy with a few anomalies that we have to manually touch afterward. I would much rather we get 99.99% of the data in even if 0.01% needs to be changed instead of waiting for perfection (community projects never have perfection).
Anyway, good talk, im off to do my weekly update from AFDC into OSM for new stations going online in the past week! Ill check back in here later!
Yeah the weird partner thing is probably difficult to put into OSM but conditional or something.
Also our data might have mislead you here. OtherEVs is if some other EVs can charge there.
There are also the magic docks ones where you have CCS1 adaptors built in. If you have CCS1 plugs (as we call them plugs/CCS1) then they are truly open to everyone.
Maybe
Tesla only: access=private I’ve always used and seems to be the norm but don’t really know how to tag.
Tesla adapter sites (otherEV=true and no CCS1 plugs) : access=partners ???
Tesla open to all (OtherEV=true with CCS1 plugs): access=yes
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station/Tesla_Motors
Says access = customers for tesla only.
But we can change the (old) wiki for that and maybe later get the (I forgot the name) automated ID tagger for branded superchargers to include the recommended/correct tags.
Also other tags there might be useful to you description for the name of the supercharger??
In the discussions for this page we are considering deleting it as it is old and inaccurate now. In OSM terms, Tesla stations are just a different brand of charging station now that it is more open and other CPOs are more widespread. I would go off the main charging_station, charge_point, and socket pages.
Magic dock stations in OSM in the US are socket:nacs=* as well as socket:type1_combo since they support both, so both tags are there. If both are present and brand=Tesla it is safe to say that is a magic dock station (at least thats part of what I am trying to cleanup).
Mentioned this thread and a special thanks to @Rovastar on the weekly “OSMUS State of Charge” I write:
1 Like
Guilty on all counts 
I’m indeed not around here much lately, as I sold my Model S, and multiple other parts of my life have become quite a bit more demanding. I do still drive an EV (2024 Ioniq 5) and have a strong interest in making high-speed charging easier and more discoverable, so perhaps at some point I’ll be in a better position to contribute again.
The “way thing” is simple dev shortsightedness on my part. The code and the data model expect an integer node ID for OSM, because the first several supercharger locations I looked at on OSM were all placed on the map as Nodes. I think it wasn’t till after those updates were released that I found a supercharger placed on the map as a Way, and it seemed like choosing an arbitrary Node from the Way satisfied the immediate need of creating a link from supercharge.info to the right location on OSM.org. I just didn’t anticipate this ambitious data sharing project. Changing this would be good to track in GitHub as an enhancement request, if it’s not already (I didn’t see it).
Thank you @GA_Kevin and @Rovastar for your partnership on this!
2 Likes
Hi @paulkva! I have created the issue here:
I added the URL schemes and the function I believe needs updating but I am not familiar with your codebase so I will leave that as a possible breadcrumb to follow! Hopefully it’s not too big of a lift!
2 Likes