There definetly will need to be a transition period and a retagging effort.
Changeing tagging in OSM is always tricky because there are so many entities involved.
I would suggest adding the new tag alongside the old one. Once we get all editors to do that we can start transition period. Having retagging efforts while also getting in touch with data consumers.
After say half a year or so a mechanical edit to delete the old tag could be done.
Biggest problem is that we might have charging sites that only have a single charger, so that they would be site and charger at the same time.
And of course having a man_made and an amenity tag in parallel would work but it wouldnât if the new one was an amenity as well.
In Europe sites usually donât have an ID (at least I havenât seen one shown on site)
the individual columns (that have one or more EVSE) usually have an ID shown somewhere. The European reference system usually goes all the way down to referencing individual plugs/EVSE.
Unfortunately I deleted all my photos but I can show one probably later today.
So in Germany/Europe the referencing usually looks like this:
Site - > no ref
Column-> ref by operator (e. G. 1234)
Soxket/EVSE - > EU ref (DEPFWE121548)
I still get different conclusions from your analyzed data.
I would argue that not every single charger qualifies as a charging site. Charging Sites I see as locations with its main purpose being charging which to me would mean more than one charger at least.
According to your data only 11k out of a total of 88k usages of amenity=charging_station would definetly qualify as a charging site.
Unfortunately the word charging station is used just as ambigously as we use the tag in OSM. From my experience, people refer to both site and single devices as stations and media seems to do so as well. When they make announcements about installing 10k new charging stations they are also referring more to individual chargers than two charging sites ( At least the announcements I read for the US). The dictionaries I check also use the word ambigously for both.
We also always have to understand that a majority of mappers most likely will not see the underlying tags. People tend to stick to the presets in the editors. So I think a bit more technical terminology would not be a huge burden to people.
Well, I should add a few more points about that.
My goal here isnât to enforce eMI3 standard in OSM tagging. OSM is independent and we should preserve that.
Iâd rather agree on amenity=charging_site instead of amenity=charging_pool if and only if both are consistent.
The point is to consider the site and devices at their actual extent without redefining them for verifiability sake (notably in open data).
As station is an already used word to refer to a device, itâs a poor idea to make it match to the site.
Itâs okay to fit to commonly used vocabulary, and we should take care of standards and existing practices even outside of OSM as well, to make our own data valuable in such an ecosystem.
Distorting definitions wonât enable us to reach this goal finally.
I just looked at two of the most popular charging maps and they both use station im the context of individual devices/plugs
Couldnât find what chargemap calls sites but Plugshare calls them locations
Whatâs broken about amenity=charge_station ? The number of plugs (could be 1) and the types can be specified. Plugshare & other websites/app show 1 node for a site, and the details such as number of plugs, power, and type of plugs.
Some people use amenity=charging_station for each individual charger, of which there may be many at a âstationâ. Also, the new proposed scheme could enable more information to be added.
You use the term âEVSEâ but never explain what it means.
The table listing the optional tags for a âcharge pointâ still has the title amenity=charging_stall
Now on to the content:
I strongly disagree with setting the definition of amenity=charging_station to mean the whole site instead of one charging device/station for backwards compatibility reasons.
Data consumers currently expect the outlet details (socket types, voltages, power output, etcâŠ) to be tagged on the amenity=charging_station object. These tags should be tagged on the individual charging devices and not on the whole site. Duplicating them on the site object is unnecessary and error prone and should be avoided. Therefore, if amenity=charging_station is defined to mean the whole site they would have to be removed from that object, thereby breaking data consumers.
Agree that amenity=charging_station can be used to map charging infrastructure at multiple granularity levels? Itâs simple(!) and it appears to work fine that way already: Some groups of chargers are aggregated into a single node, with capacity=N (e.g. [1]), in other cases mappers have been able to split into multiple individual chargers providing finer level of geographical/electrical/commercial information (e.g. [2], [3]).
Continuing to use the single existing tag (amenity=charging_station) for multiple levels of granularity, also avoids locking our data model onto a terminology that might not have matured completely yet (EVSE/pool/station/point/âŠ).
This still allows adding a site relation (or maybe simpler, just an enclosing way) on top of the 1-N charging_station, to indicate some sort of logical grouping. It is not clear to me what the criteria for grouping would be, though, so not really a fan of doing that⊠Same operator? Within x meters of each other? Same payment method?
I honstely have been thinking about that for a while and would be my preferred method.
I think we are covering individual devices quite well. For dedicated sites like Braintree I think would be nice to cover that either via an area or even better a site relation. The relation could also include amenities available for people charging their cars.
Individual devices would always be nodes and sites would be areas or relations.
I guess my take is that there really isnât a clear fundamental difference, both are just collections of sockets/cables (in lack of a better term) more or less suitable for charging specific electric vehicles.
But maybe I misunderstand what you mean with site? To you, what distinguishes a node and a site?
The real world of EV charging is not yet at the same comfortable level of gasoline infrastructure: A gas station is a well defined concept, and drivers pretty much know with certainty that any gas station will satisfy their refueling needs, EV driver must take more parameters into consideration.
Thus, as an electric vehicle user, I donât (think I) care if a socket belongs to this or that station, I care whether it has the right configuration for charging my vehicle. Specifically socket type, output power, and payment method would be very important. In my experience these parameters are often very different for sockets placed right next to each other. This naturally leads (me) to mapping at higher granularity than what would correspond to a gas station.
Another difference to gasoline infrastructure is that, due to the fairly long charging times, live availability status of each socket is important (and probably available online somewhere). Iâm not sure if/how OSM can support this aspect, but it is probably worth taking into consideration.
Well this is the reason why I got involved in this thread. In the UK we are set to get legislated access to live data from the chargepoint owners. It makes sense to make sure we can link to that via suitable ref tag.
As noted, these early days of EV use are not a good indication of the future. Sockets are being standardised so worrying about the right socket will in time disappear.
Personally from a user point of view, I do think sites are useful. In search results you want to know where the sites are that can provide a rapid change on a long distance trip. Flooding search results with every single charge point is not helpful. I think Google have got this right in the search result I showed earlier.
Summary: I do feel it is useful to map sites and (somehow) relate them to the individual chargepoints available at that site. My concern is that if we donât agree, OSM will just be a mess for this feature.
The, perhaps too, simple way to disambiguate between a site and a single charger* would be to, for the former, add a tag indicating the number of chargers.
* I note that this is not the correct terminology, for DC chargers the bits with the cables, plugs and screen are actually dispensers (aka no HV circuitry) and for AC chargers (aka âwallboxâ), the charger is in the vehicle.
Ok. So map the site with amenity=charging_station and capacity=x. How would I then map the individual âdespensersâ/âwallboxesâ (as you call them)?
