Since 2020 there have been slow-burning discussions on the discussion page for amenity=charging_station. regarding the use of the tag.
Comparable to gas stations (amenity=fuel) which usually have multiple fuel pumps (man_made=fuel_pump or vending) charging devices often appear in clusters/sites. A lot of times one charger has capacity for one or two vehicles.
The Wiki and OSM didn’t distinguish between individual chargers and sites which leads to confusion and to fact that the tag is being used for both at the moment.
Since capabilities among individual chargers (I have seen 11kW chargers next to 150 kW chargers), we need the ability to represent both.
I’m therefore reaching out to more people than possible in the discussion page to see if we can come up with a solution.
A user on the discussion page hints at the official definition for charging station which would indicate it being the devices
The dictionary reflects more the common use of language where a charging station can be the site as well as the device
Also while we are on the topic. Maybe we find some good ideas for battery swap stations as well
The terminology here where I live (UK) is that one electric vehicle (EV) charging point might have four chargers and eight charging bays (because each charger can charge two vehicles at the same time).
Personally I don’t mind how they are mapped. It would be good if it was easy to map that there is a charging point/station and then add detail later. Similar to how most people don’t bother drawing individual parking bays for non-electric cars, and no one in their right mind would draw individual cycle parking stands. So maybe the number of chargers and/or bays and their wattage could initially be tagged on the charging_station node, and then later that amenity=charging_station could get refined into a way with bays and individual chargers (for which a new tag would need to be invented)?
If you’re thinking about this, maybe you can also think about how to tag private ones? Near where I live there are now charging points reserved for car sharing. I’m not sure if and how these should be tagged (as a tag on the amenity=car_sharing or as a separate amenity=charging_station with an access tag?). To complicate things, there is at least one site with two bays where one is for use by the public while the other is reserved for the car sharing.
I’ve never mapped a large site, but I’ve mapped a few sites with a few devices next to each other, I did them as amenity=charging_station per device. I think we should have a way to map a site, weather that’s amenity=charging_station per site, a new tag per site or below.
Are we not expecting traditional petrol stations/gas stations/amenity=fuel to start offering electric refueling? If so will we end up with something like: amenity=fuelfuel:electric=yes? That could leave amenity=charging_station to the physical device.
In refining the tagging rules we need to be able to ater to this site, right down to cases where a few EV chargers have been put in alongside (existing) street parking. In this later example you can only really tag the chargers as nodes (as the parking bays are not dedicated EV bays) but we need to be able to relate the few nodes that make up a collection together as this is likely how the live data feed will work when that is rolled out as Open Data here in the UK.
As an example of the latter, see these diagonal bays on G StreetView. The imagery is old but that there are about 4 chargers servicing these bays. No need to have an EV to park there, and even if you have an EV you can park but not charge if you like.
I suspect what we’ll need is a Relation. The Gridserve example above has capacity for 46 cars but that’s across a set of physical chargers (“pumps” in the old petrol world) with 7 different socket/wattage combinations.
When we get the live data following the UK legislation that is planned, I suspect they will submit this as one site with details on availability of each bay (just as Google maps shows it).
So mapping the site and then adding the bays or chargers as nodes in the relation may be the best way to go…
I’ll keep working on this for the UK community this week.
The examples I’ve seen here in Edinburgh all have dedicated bays. This suggests that we need a way to distinguish chargers with dedicated bays from those without (users might prefer the former because they’re more likely to find a free one). The Wiki also points to a capacity:charging=* key for an amenity=parking so there is some risk of having the same information in the database twice.
In a way, I almost think we are best to see what data format end up being legislated for. Last I heard for the UK, they were examining OCPI (Open Charge Point Interface) protocol but had asked Valtech Ltd to do some research:
Have mapped quite a few, both bays and charger points, at times more bays than charging plugs, some having 3 different plugs, but only 1 usable at a time, so using capacity=n for how many are serviced simultaneously and capacity=n on the bays mapped as parking spaces. In ID Editor it’s fairly easy as there’s a preset wizard that adds brand tags on the go such as for EnelX and BeCharge. There’s also charging stations that have a sign to say that they have no power given the electricity company has not yet laid the cables, one now going 2 years at the Silvi Marina rail station.
that’s funny. I added the forecourt initially. Still needs the individual chargers
Currently the whole site is tagged as a rest area.
From the comments so far it seems most logical that if a new tag would be introduced, it would be for the site. The individual stations(devices) are quite well documented (with socket:* and stuff) and covered with amenity=charging_station.
I think a tag like amenity=charging_pool or =charging_site would allow roughly tagging a site with multiple chargers. And using it as a relation could cover more complex examples like the Gridserve Braintree Electric Forecourt. I could imagine that the the site relation for it would include at least each charger and could include the parking areas, the outline and maybe amenities.
We need to think about how amenity=charging_station will be used by maps and apps. For example, it will be unpractical to get all 20 individual chargers at a charging site listed in the search query for the closest charging station. It would be like mapping each individual parking space in a car park. If OSM wants to be relevant for use cases in the real world we need to get clarity on how amenity=charging_station should be defined. In my opinion, the only solution which makes sense from a usage point of view is to let the main tag amenity=charging_station be used to represent the site, i.e. a group of chargers by one operator or brand, or for just a group of chargers, or even a single, stand-alone charger, outside an office or in a street. The socket tags are used to show the number and variety of connections available on the site.
The amenity=charging_station was derived from the amenity=fuel tag, which is used for the fuel station site, not for each pump. Pumps may be tagged with man_made=pump. Similarly, we could have a man_made=charging_point (or similar) tag if there is a desire to micro map charging each column (although I do not see myself any advantage in duplicating the same information for many adjacent nodes). Creating separate site relations is too complicated to get popular, I think.
The amenity=charging_station tag is already being used for sites by what seems to be the majority of users in many countries. For example, almost all of the Tesla Supercharger sites seems to be mapped this way. The “station” name itself, or the station concept, and the analogy with fuel stations, also seems to match well with what these sites are called in many languages.
The amenity=charging_station tag is already being used for sites by what seems to be the majority of users in many countries. For example, almost all of the Tesla Supercharger sites seems to be mapped this way.
I don’t think the majority of users use it for the whole site. It seems like currently it’s split pretty evenly between sites and devices.
At least looking at the numbers on taginfo just a bit over 50% of charging stations have either capacity=2 (42.8%) or capacity=1 (8.2%) which indicates the most likely use as individual charger. https://taginfo.openstreetmap.org/tags/amenity=charging_station#combinations
I think this makes the most sense. I’ve been mapping charging stations as one node per location, with amenity=charging_station. In the future, when we have a tag for the individual charging stalls/bays/sockets/whatever I will start to map those as well. And maybe a site relation to signify that they all belong together?
In my opinion using the current tag for sites falls short when you go away from big charging networks like Tesla’s that have pretty much have one type of charger per site. But I have seen sites that have 3 chargers each with different socket configurations (type 2; CCS; Chademo or only one or two of those) and even with if they have the same sockets, they sometimes have different power ratings depending on the individual charger.
That’s why we have the detailed tagging documented like that in the Wiki atm.
Even all the examples show individual chargers and not charging sites.
It also brings us back to the issue with searching/rendering things.
As people brought up, if you have each individual charger in a site show up in a search, it can be overwhelming. But on the other hand you would probably want to have a single charger in a parking lot show up when you looking for charging opportunities.
I think we need to propose a new tag for the individual charging stalls, and clearly document which tags go where. This whole thing has confused me before.
Tags like capacity, network, name, etc would go on the amenity=charging_station (which there is only one of), and output tags, etc would go on the individual stalls.