Bulk import of Tesla Superchargers in the United States

Communities United States
1

Hello again OSM US Community! Following the successful discussion and import of Tesla Superchargers in Florida, I am ready to proceed with the rest of the United States. Please see this repo for the script I used and csv output:

I have gone through and cleaned up about a dozen or so address fields (mainly duplicating city/state in street) and had to manually adjust the ref:plugshare and capacity:disabled columns (for some reason I can’t get them with no decimal places in the script.)

Please let me know if there are any questions, comments, or concerns on this import. I am planning on conflating into JOSM on Sunday on my return trip from SotM so please feel free to comment here or talk to me in-person (gasp) at the conference! This will likely take the place of this weeks AFDC import on Sunday’s “State of Charge.”

1 Like
2

I haven’t paid attention to the previous imports, so my apologies if this is covered elsewhere, but:

  • What’s the “conflation” process? I know some of these already exist; in those cases are just the tags being updated or also the position?
    • For instance, this way is around the parking area for charging. Whereas the row in the csv with ref:supercharge_info of 4370 has it at just a single nearby point 42.09855,-72.0726
  • The addr:postcode field seems to not include leading zeroes of the zip code. (And do chargers really have zip codes? Like one can write a letter to them?)
3

Conflation uses the Conflation plugin in JOSM to have the CSV as “reference” and an overpass query as the “subject”:

[out:json][timeout:25];
{{geocodeArea:United States of America}}->.searchArea;
nwr["amenity"="charging_station"]["brand"="Tesla Supercharger"](area.searchArea);
out meta;

For some things, like capacity or website it is trusted to be accurate from the reference, but things like the location are kept from the existing OSM node/way/relation. So in your example, the information from the CSV will be merged with the existing way to be updated as version 2 of this way (if done at the time of writing.)

Ya know, that’s a known issue with my script and thank you for the reminder. I’ll go through and update that. It comes from the fact that it is treated as a number not a string during the script so it cuts the leading zero from the CSV. Thanks for pointing this out!

Chargers have zip codes so they can have a complete address so routers and data consumers can reference them. You can’t write a letter to a charging station, but you can navigate to one.

2 Likes
4

SD ones look fine.

1 Like
5

@PeterCooperJr, The post codes are now properly showing leading zeros. Can you please confirm it looks ok on your side?

6

Conflation has been done for nodes and ways (thanks for pointing that out @Rovastar). Due to limitations of the conflation tool in JOSM, relations are not included. Following import, I will go back for each relation and merge by hand any (single digit I believe) Superchargers currently tagged as a relation in the US.

Please see here for the updated JOSM and OSM files post-conflation:

When conflating I also removed some duplicate incorrect information already existing in OSM (such as charging_station:output which is not a valid tag and a duplicate of the imported and conflated socket:nacs:output.) Some fields are static across all Tesla Superchargers in the US, and were updated at time of conflation:

amenity=charging_station
authentication:app=yes
bicycle=no
brand=Tesla Supercharger
brand:website=https://www.tesla.com/supercharger
brand:wikidata=Q17089620
brand:wikipedia=en:Tesla Supercharger
bus=no
fee=yes
frequency=0
hgv=no
motorcar=designated
network=Supercharger
network:website=https://www.tesla.com/supercharger
network:wikidata=Q17089620
opening_hours=24/7
operator=Tesla, Inc.
operator:wikidata=Q478214
operator:wikipedia=en:Tesla, Inc.
reservation=no
scooter=no
source=https://supercharge.info

This should be the final file / iteration of the US import, I am aiming for 99%+ accuracy but I do not expect there to be no issues post-import. Please let me know if you see anything in the next day or so and if you notice anything wonky post-import.

As always, any questions, comments, or concerns are welcome.

7

It seems not to work correctly updating the socket fields if there are multiple stall types.

I should have picked up on this before. Sorry.

These will have the semicolon ; separator in OSM speak as each stall type has a different kW output.
So say supercharge.info will have
socket:nacs=40;56
socket:nacs:output=150;250

8

Let’s add that as the first thing to do on a second pass or ongoing sync. Is there anything else for what we have now that’s incorrect?

9

mostly looks good. It doesn’t seem to have updated any of the ways though.

10

I see quite a few if you search /way in the .osm, which did it miss? Edit: I think I see it, seems to add the node to the way not just copy the tags over. Maybe as a way to preserve history?

11

the ways are in there 100+ of them. The tags don’t appear to have changed.

Do you need to run the just the ways first and separately to make sure they match and update the tags?

12

Probably, would need to be on a second run. If we get most of the data via nodes I think that’s a fantastic first pass. Then we can figure out the semicolons and ways and such.

1 Like
13

Yeah let’s get just the nodes first. That is the bulk of them anyway.

1 Like
14

Hello! I just saw some results of the bulk edit of US Superchargers. This is a great idea, but there are some issues. I first saw this on the Aurora, CO, Supercharger (node 12604453965, sorry, I’m limited to 3 URLs in a post at the moment, so this one got de-URL-ified), which I created and have been making most of the edits on (along with a bunch of new stations in the western US).

I have 3 areas of concern:

  1. Data that was lost
  2. Tags that are problematic
  3. Tags of questionable utility

Data that was lost
————————————————————————
a) Source URLs got lost, which lost exact source info that didn’t come from supercharge.info, so now source is inaccurate. Many times it has come from the teslamotorsclub forum, where people post photos so we can see exactly where a station is and other details. If I use TMC I put the thread URL in source.

b) Note got overwritten, losing info about access and which cars can charge, depending on MagicDock, NACS, or Tesla-only. Where does that go now?

I have been putting this in note (because I don’t yet know where else to put it and description didn’t seem right), depending on the situation:

Note if MagicDock:
Non-Telsas can charge here. Charging cables use the Tesla MagicDock, so each cable contains both a NACS (Tesla) plug and a CCS Combo1 (type1_combo) adapter plug, but only one plug can be used at a time.

Note if NACS:
Non-Telsas can charge here. NACS (Tesla) receptacle or adapter required.

Note if Tesla-only:
Currently, only Tesla vehicles can charge here. Posts do not have either MagicDock (CCS1 adapter) or non-Tesla NACS port/adapter support. Therefore, access=customers and not access=yes (public).

Tags that are problematic
————————————————————————
a) Website URL is using a syntax that is seen on Tesla’s Supercharger list page (and that page is not being kept up-to-date), though it does work, such as:
https://www.tesla.com/findus/location/supercharger/404915

Once on that page, if you click the map, you’ll see it briefly redirect to the URL syntax used on supercharge dot info (except for old stations):
https://www.tesla.com/findus?location=404915

and then redirect again to a messy URL with Lat/Long and the station ID at the end:
https://www.tesla.com/findus?bounds=40.11761452959175%2C-104.03585180859376%2C39.21272282026969%2C-105.68929419140626&location=404915

So the question is which URL is better?

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

c) maxstay=0 might be misleading to new users of a Supercharger station. While there’s no explicit time limit, there is a 5-minute grace period after charging is complete or idle fees begin to pile up.

d) Why list ref:plugshare? They are often wrong and after a few tries, I gave up on trying to get them to change anything.

e) Why list a separate ref:supercharge_info instead of leaving it in the source as a URL that’s instantly clickable from OSM in a web browser?

Tags of questionable utility
————————————————————————————
Are these tags really needed? bicycle=no, bus=no, hgv=0, motorcar=designated, reservation=no, scooter=no ?

For example, why do we need bus? You’re there in a car, but I guess this is really about busses charging there. Tesla has not said anything about that AFAIK, and the Robotaxis might charge there. Are they busses? Probably not. But then you might want to put taxi=no or robotaxi=no, so where does this end?

Also, Tesla hasn’t said anything about an hgv. Someday a Tesla Semi might want to charge, and they will fit in a standard-width stall. Not sure if any Tesla Semis have a NACS port, though, in addition to their MegaCharger port, but that could happen for independent truckers who park their Semi at home.

Interested in replies!
@TheNightRider here and on OSM. @electrons4u@tmc

1 Like
15

Hey @TheNightRider! Thanks for writing in! I see this is your first time on the forums - welcome! (Correction: it is not, it is in 4 months when I reread, apologies but still hello!)

And thank you for double checking me! Imports like this take a few passes to get 100% right and this was pass 1 so feedback like yours is very valuable! Allow me to address each point in a quote-response manner, if I miss something, please call me out!

Is Tesla Motor Club’s licence compatible with OSM? When I took a look at this field I thought it better to go with a source I know for sure has given OSM permission but if they have and I just missed that, we can go back on the history and add a semicolon list if you’d really like. 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!

2 parts to this one! The first is note on the wiki states it is for other mappers, not for the end user, those descriptions you had would better go to description if you were to go that way. That said, we have been working on a way to distinguish these 3 types of Superchargers, and even though it’s not perfect since technically only “Tesla partners” can use Superchargers, not just anyone with a CCS → NACS adapter, we’ve been using the following for this import project:

OSM Values Meaning
access=yes
socket:nacs		 All Tesla partner vehicles can charge here with a personal adapter.
“Open to other EVs”
access=yes
socket:nacs
socket:type1_combo		 All Tesla partner vehicles can charge here and an adapter is provided.
“Magic Dock”
access=customers
socket:nacs		 Only Tesla vehicles may charge here.
“V2 Station”

You’ll notice all 3 have socket:nacs but are distinguished by their secondary socket types and access. Hope this helps address your concern with that!

I may have to throw this one to @Rovastar as the website was his idea to add and gave me the schema of using the Tesla ID field from their allSites endpoint. Personally, if it redirects, then that’s not the worst thing in the world to me as its better to have all these have a website than not if it can be done programmatically but I’m open to discussion here!

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!

Theoretically, you can stay at a Supercharger an unlimited amount of time… your wallet will be unhappily light… but you can do it. Typically this tag is used in parking scenarios where you would be towed or otherwise legally problematic if you overstayed your welcome. There has been some discussion recently on the grace periods and how to tag them, and I have a few ideas, but likely they will be added to and surround charge or fee when the consensus is formed.

I don’t like it either but it is in an effort to link as many databases as we can so OSM is the “hub” for EV charging not just another spoke. People do use and recommend PlugShare and since we have the data it is useful to provide, much the same as ref:ocm for OpenChargeMap, where we haven’t done an import (yet) but do know some IDs.

This serves several purposes in this import. The first is quality control, we can now query to see where information has been added, where is may be missing, and in an effort to be helpful to the folks who graciously let us use their data, helps them identify OSM stations they may not have on their database. The second is much the same as above with PlugShare and OCM, it is a useful identifier to link our databases with a common value to prevent duplication or to help facilitate updates easier.

Yes, some charging stations do allow for these to charge, but no Tesla ones do. They are designated for motorcar use. Since OSM does not distinguish between size of charging station (be it e-bike to Megawatt charging) these tags help explicitly notate what the station serves.

I’m going to file this under “when this happens let’s discuss how to best tag it.” I suspect they may want to use socket:mcs for large vehicles like that which would likely not be automatically compatible with existing Superchargers… all speculation though and we can discuss if/when that happens.

Again, thank you so much for your feedback and questions, I hope I addressed each in a way that is clear and understandable! Let me know if there’s anything else I can help with!

1 Like
16

I have a problem with ‘access=yes’, when it isn’t open to any vehicle (even with an adapter), they are only open to ‘Tesla partner vehicle’ as you put it. access=customers seems better, but then that would look like the last case (V2). My suggestion is access=customers for the 1st case, access=tesla_only for the last case

2 Likes
17

I think it is probably the best link to use. It is static page so give more compatibility for more users. Also I think it is better not to link to a competing map service directly in OSM.
I don’t find a massive issue with pages not being kept up to data. I’m not sure where you get that idea. I found no difference to the accuracy than to other tesla sources for a site really as sometimes they are all a little off.

Generally chatging_station does not say when you can only use one connector where the charing_point has multiple ones that you could use. Nothing wrong with adding notes, etc to refer to this but I expect tens of thousands of charging_stations in some are like this, it can be implied often with the capacity tag count and each socket:(type) tag.

It seems we are using the best practice already in OSM (if best practice is not an oxymoron with OSM) for tagging the different socket and access of the station.

Maybe it would be useful but to have that as well but I don’t really think OSM tags should be overrun with links. But no real objections to having at as ref:supercharge_info:website.

Welcome to OpenStreetMap :joy:

18

Yeh everyone has opinions on this but access=customer is used for when it is tesla only so this follows the way these are generally tagged in OSM already.

19

@GA_Kevin The main thing I dislike about source supercharge.info is that it is going to be applied to the stuff that is not in supercharge.info. You should only add that source if there is a ref.
All the dubious /wrong tagged superchargers that are likely 1 or 2 stall destination chargers that you found it blanket added the source to them when clear you didn’t get it from there.

20

@Rovastar yeah, seems source should be stuck to a subkey if anywhere. Perhaps just stick with the source on the changeset (which I did). Easy enough to remove on the next run.