During the conflation step with existing OSM data, there was two item(s) to conflate, which which were skipped on import. bp pulse continued to open their California gigahubs with a new station right outside LAX with 48 stalls! A massive bp station!
There is a new IONNA station, and many, many more in the permitting / construction phase. This week’s addition is at a Sheetz in Obetz, Ohio (south of Columbus):
I have started this week treating the Mercedes-Benz High-Power Charging network as it’s own network, despite the AFDC still listing them as a ChargePoint station. This is due to their shift to using Alpitronic HYC400 dispensers as opposed to ChargePoint dispensers. They can still be initiated via ChargePoint, but that is much the same as IONNA where networks are starting to interoperate. For IONNA, I have been using payment:app:chargepoint=yes and I would do the same on these MB HPC stations.
A comment was brought up last week on the weekly changeset that postcodes with leading zeroes are being cut short. This is mainly an issue in Massachusetts I am seeing. For this week, I will go back and edit the 1 new station in MA manually, but future weeks I want to update my python script to keep the leading zero (and also append the +4 zip codes.)
New in the Charging Station OSM world
Progress on the EV station cleanup has slowed as my attention has focused more to imports than cleanup. So far the following states have been updated: Georgia, South Carolina, Florida
The supercharge.info import is starting to take shape. Please take a look at my post about a bulk import of Florida Supercharger stations. If no objection, I will update that to OSM mid-week and start to prep the rest of the US file for approval. Thank you to @Rovastar yet again this week for helping so much with this!
Speaking of Tesla, there is a proposal in the voting stage to deprecate the socket:tesla_supercharger and related keys as they are now following a standard worldwide. Please vote approve on the proposal page on the OSM Wiki. A huge shout-out to @RobJN for putting this together. For us here in the US, Tesla has some different access and socket availability but all stations have socket:nacs, please see this table for the access information:
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”
When in doubt, tag as socket:nacs with the value as capacity and we can add additional info later!
I have left a comment on the discussion page of Key:maxstay wiki page regarding adding EV chargers to this key. Specifically those which limit your charge to a percentage and then are expected to leave such as some high-demand Electrify America stations. Any additional comment is welcome! This isn’t widespread right now in the US but if EV adoption continues and site construction / expansion slows due to NEVI grants from the federal government drying up, it may become more common on busy corridors.
COME SAY HI AT SOTM US THIS WEEK IN BOSTON! I would love to talk about EV infrastructure or anything else OSM related! I may have just started in December, but I have been looking forward to this week for months!
A Special Thanks
A very special thanks is in order to @mtmail for engaging with my last changeset and offering some insight on postcodes! Every bit makes these imports better!
Are you planning to add the capacity, and socket:(socket type):output to these imports? Most/all of this import seems missing this.
I consider capacity (amount of charge ports), what sockets and the power of the sockets some of the core important elements to be charge stations. As you really want to know the size of the station and what cars and what juice they can give out as some of the most important info.
Are you looking at (or have seen) the AFDC ports dataset for this (the additional and much larger than the stations dataset)?
For key maxstay i posted on the talk about that I don’t think we should use that key. I think a new key needs creating for this.
Capacity and outputs aren’t part of the AFDC exports I get for the overall station, but every entry has socket information. Some are ‘yes’ because the AFDC will say something like “there are 4 DC chargers” then in a different column say “there are J1722COMBO CHADEMO connectors here” so there’s no way to tell how many of each, only that they exist.
I have seen the ports dataset but that’s not as well kept from what I’ve seen and I have my hands full with the stations as a whole, much less the points. Maybe one day, it would be nice.
Thanks for the comment, I’m not sure I’m completely sold on it not being maxstay but I’m looking forward to what we come up with!
Yeah I get it the ports one is a lot more work.
I do think it has the most useful information about the station in it though (not taking about adding charging_points to osm)
I am not sure what you mean about not being well kept. It seem pretty good now (compared to a year ago) And it is directly used for populating their website.eg https://afdc.energy.gov/stations#/station/133326
The biggest ‘problem’ I have seen in their data is the way Chargepoint and some others (thankfully I think rivian I now fixed this) submit their charge points and charge stations.
If it was easy to get a combined csv would you use that? I am wondering if running a bit of code that just spits out the relevant fields in a csv which combines the stations and ports to a more useable form .i think a can get AI to write something like that.
Yes, absolutely. AI is what wrote the python I use for this and supercharge info so I have no doubt it could make a script to combine that, just a matter of getting it together and verified accurate. TBH I have more issues with LibreCalc than python with these though. I’m getting a laptop tomorrow so I’ll not only have a raspberry pi so I should be able to do a lot more more efficiently.
And you’re probably right about quality, I didn’t look too far into it because of the size, my thought was more “I’ll get stations in order then I can work on points” but I see what you’re saying about points info on the station node being useful and agree!
Yeah I had used AI much until recently but it is amazing for simple stuff like this (I’ve been using python too I know nothing about python tbh) . I haven’t done much proper coding for decades but it is sooo easy.
I can give you a hand if you want but I think it should be easy getting AI to do it.
Personally I would wait on your next import until this is done. It will make the data some much richer.
On other news about this I have updated a load of charging stuff for the NSI that is relevant to the US.
Maybe you want to add these to the script too.
Too be honest if you trust the NSI and want to match we could use AI to match with the NSI file on GitHub for the relevant networks for the brand. But let’s do baby steps first.
There’s a few corrections I have but I’ll compile them into a PR once I get time to go through everything. Mainly brand capitalization and display names (“bp pulse” vs “BP Pulse”; “Circle K Charge” vs “Circle K”; etc.)
the display names are capitalised in the files (ignore my text description with the sloppy capitalisation). Hold fire on circle K that is worldwide and I’m not sure what it is in other countries.
Generally I have got NSI as I have more in draft I am adding and modifying already. There is loads more tidying up to do and loads more to add. I don’t want too many edit conflicts. This pull request was just the first one of many.
